Segmentation fault
-
Hmm, that's really difficult to detect what's wrong there and my debugging skills on Linux are terrible. I could try and take a look if you send me the link to your repository to see why the scripts are not detected properly.
BTW, I assume you know you're running a Debug version of HISE there, which is like 600% slower than the normal build?
-
Yeah I compiled the debug version to see if it would help solve the problem :)
Here's the repo for my framework libraries and modules - it's the modules that HISE can't find since I renamed a few of them. https://github.com/davidhealey/HISE-Scripting-Framework
The repo for the project is here, I haven't uploaded the .hip though because I put a gitignore for them, I was going to just upload the xml backups. - https://github.com/davidhealey/librewave_woodwinds
I've uploaded the .hip file here so I don't have to mess around with the gitignore - http://www.filedropper.com/altoflute
-
I opened the .hip in the older version of HISE (22/11/17) and saved it as an XML which I then edited in a text editor to include the correct paths and file names and I'm now able to open this in the latest version of HISE - hopefully I didn't lose anything by going back to the old version... I've pushed this XML backup to my repo. One thing I've noticed, which I saw in the latest version before I screwed things up by renaming files, is that my main interface won't show up unless I open it in the preview window or as a popout, is this intentional?
Another thing I came across while editing the XML, for externally linked scripts it uses
{EXTERNAL_SCRIPT}at the start of the path, I think I mentioned this in another thread, but would it be possible to get HISE to search the{GLOBAL_SCRIPT_FOLDER}if it can't find the external script? Then if I move files around or move to a different system it will still be able to link the correct externals without them having to be manually relinked (assuming the filenames haven't been changed and the global script folder link has been updated). -
I've just pushed a fix to a similar crash on macOS. However I am currently working on the
script_valuetreebranch (I'll merge this to master in a few days). Can you check if this solves your issue?And yes, the interface doesn't show up in the module list anymore because it was polluting the UI rendering and I never used it.
And good idea with the fallback to the
{GLOBAL_SCRIPT_FOLDER}location, I'll do that. -
That didn't fix it unfortunately, and I have this weird problem (also happens with the master branch) with none of the GUIs showing up.
-
Alright, the crash is fixed (it was complaining because the error popups were launched by the sample loading thread).
The GUIs are empty because it can't find the external files. If you want to keep your sanity, I'd suggest not relying too much on the external file feature, it's something I never use so it is not guaranteed to be as stable as something I am using in my daily routine.
-
Have you checked out the Git submodule feature? It basically allows you to link another repository into a subfolder, so if you create a submodule for your scripting framework in your Scripts folder, you should be able to retain your workflow. Plus people will not need to clone another repository and redirect their global script folder - unless you don't want people to be able to compile your software like Ardour does :)
-
I haven't seen the sub module feature, that sounds like a good solution I shall check it out
-
It's pretty easy, just go into your script folder, type
git submodule add LINK_TO_REPOand it will fetch it from there.Then just do a search and replace
/media/dave/work1/Xtant Audio/Products/Virtual Instruments/0Frameworks/->{PROJECT_FOLDER}in your .xml and you're back on track :) -
I just noticed, the front interface isn't an external script but yet it doesn't show up and the playable range script it's picking up the one combo box but not the rest of it, I'm guessing it's also finding the mic mixer script since it expands to the correct height...
