@christoph-hart said in Building develop for C++ API:
FYI I went through the codebase today and fixed compilation with the flag, but I haven't pushed it yet. It was only about 1200 compilation errors, so that was easy :)
Oh wow, that's awesome! Thank you so much for that, looking forward to the update. I didn't dare to hope!
I'm curious which way you fixed it :-)
And thanks for the pointers, I will read into that.
@christoph-hart no worries, thanks for answering.
Switching off the strict ref counter check indeed is a suitable workaround. I was using the defaults in my Projucer project.
It gets me a lot further. Now I am stuck with the ModulatorChain.
Seems you have some trick to create the Modulators from a template, I have no idea how that is working. I did find the `XyzModulatorFactoryType::fillTypeNameList()``` methods but have no idea if or where to call them. They are not static. I guess there is some entry point that sets up all that properly.
Thanks again,
Daniel
Hi @Christoph-Hart and all,
following your advice here (updating streaming_example) I setup a fresh JUCE 6 project and added the necessary modules.
Without adding any own code and not even at the point to call the factory it doesn't compile. The reason seems to be internal changes, that many containers use now ReferenceCountedObject<>::Ptr (which is great I think).
But the accessor functions return raw pointers, like seen here:
There are two ways to fix it, either we return a Ptr or add .get() to each return statement. A warning, they are many!
I would volunteer to go through the code and fix those making it compile, if you will integrate those changes upstream (I don't intend to maintain a fork).
Which way do you want me to fix it?
My advice would be adding
using Ptr = ReferenceCountedObjectPtr<ActionBase>;
and return an ActionBase::Ptr instead.
Thanks,
Daniel
Great, thank you for the answers and sorry for interrupting your vacation.
Sorry for teasing, the comment is from a commit (see .gitmodules ;-) )
I'll have a closer look at the develop branch. My questions stem from the fact that I never used the full features of HISE, and actually the clients codebase doesn't either, even though it is based on an old export.
Maybe I will know more details next week when you are back.
Cheers and enjoy the rest of your vacation
Daniel
Hi @Christoph-Hart,
how is the status with the bundled JUCE sources?
You decided 6 years ago to use your own JUCE version ("because JUCE is too buggy").
Some time has passed and I think the JUCE API has greatly improved.
Do you consider moving back to a vanilla JUCE?
What are the major pain points not to do so?
I am tasked with updating a client project which involves a lot of C++ code around HISE, and I would like to remove as many dependencies as possible.
Thanks in advance
Daniel
So I spent the night updating the said modules, here is the PR:
https://github.com/christophhart/HISE/pull/212
Sadly the AppVeyor CI fails already for a while, I would have been curious if windows builds as well.
The streaming_example needs a few modifications as well (e.g. runThread()). I'll push a PR when I tidied it up a bit.
The createMemoryMappedReader I left out, since that might require changes in the rest of HISE ass well, but updating all of HISE to juce6 is a bit big task, especially as I am only interested in the sampler.
Let me know if that works for you or what I should change/improve. Would love to see that merged.
Cheers
Hi everybody,
I just entered the wagon a couple of weeks back. I am trying to make a project future proof, i.e. decoupling from the bespoke projucer and use hi_streaming as explained in streaming_example.
To do so I am updating the hi_lac and hi_streaming to compile with JUCE 6.x (removing ScopedPointer and the warnings).
Two questions:
Thanks and happy coding