@BM_FORUM EDIT: Further to all this, I now have it where I am able to get the entire thing functioning from a sample playback perspective, minus the script. So something is obviously bugging it out somewhere. So I'll just begin introducing one element at a time until I find the culprit... If I ever do! Bit of a ghost this one.

@d-healey The plot thickens by the minute here... So now, with all sample maps removed and samplers switched to off, it does indeed load. But if I try to either switch on a sampler, or unpurge a sampler it crashes immediately. This is with no sample map loaded, so no actual samples to unpurge or load in...
Creating a new project, and loading in a sample map from this project, I can purge and unpurge with no issue so it must be linked to a scripting issue somehow but there's really not a huge amount going on aside from basic controls and various volume controls/keyswitches. I even cleared out the entire noteOn and noteOff sections leaving only the interface script to the same effect. Here's a short vid with it doing the crash. With no samples even loaded... Just a sampler that I change to unpurged and then switch on...

P.s - Just after posting this I also took the entire script out (interface, onNote, noteOff) leaving only the GUI elements that were made in the interface editor. Other than that it was clear, and still did this... very weird. Given the exact same sample data works fine in a clean instrument. Perhaps its a audio settings thing, but I can't see it for love nor money!

@d-healey Okay this is what I'm getting, so I think perhaps there's an issue with the JUCE files that are packaged with HISE? Which perhaps wouldn't be an issue is I just grabbed JUCE directly, but when I tried that a day or so ago it didn't allow for the 'indie' level changes until my licence reflects that (splashscreen etc...).
Of course that's only an assumption, maybe something else has gone wrong here... For additional information, I slimmed down the original projects initial load by purging all the samples before saving on Win and attempting again in Mac in an attempt to remove some of the initial weight of loading... Anyway, here's a screen shot of what happened when trying to open this project via an xCode build:

@d-healey Thinking about it, I suppose it'll just be a case of saving variations where it's increasingly stripped back on Windows and see when it starts to pull through OK... I'll see where that gets me!

@d-healey It's crashing the debug version out too as soon as it loads... It gets past loading all the sampleMaps in and all the way to finishing the code off and then crashes without warning. The report is the same, unless there is some other report stored somewhere in debug mode when loading?
I also copied just the script side of things and whilst I could input it, I don't think it compiled very far in HISE because of all the missing sliders and panels etc... But didn't crash.
Don't really know what else to do here, is there a way of copying individually the interface controls settings (sliders with names etc... and their parameter settings), then the module section for containers and samplers etc... then I can copy them in one at a time until it crashes perhaps? Though I doubt that is possible...

@d-healey Right it seems to be an issue with the project specifically. I just created a simple sine wave & keyboard floating tile project on both WIN & MAC and they both worked fine on the other... So I exported the snippet from the main project and that confirmed without trying to load any samples etc... that it won't open on Mac.
Here's some detail about the crash (attached report as PDF), and specifically thread 5 (I've posted this below, but full report attached) in this report to my eyes appears to be the issue... Which appears to be about audio processing and modulators. Is there any further trouble shoots I could try here that jumps to mind?

(Both OS running develop 2.1 (650))

Thanks

Thread 5 Crashed:: com.apple.audio.IOThread.client
0   libvDSP.dylib                 	0x00007fff367e60c0 0x7fff367e4000 + 8384
1   com.hartinstruments.HISEStandalone	0x000000010df3fa77 hise::GlobalTimeVariantModulator::calculateBlock(int, int) + 855
2   com.hartinstruments.HISEStandalone	0x000000010de779c2 hise::TimeVariantModulator::render(float*, float*, int, int) + 162
3   com.hartinstruments.HISEStandalone	0x000000010de77891 hise::ModulatorChain::ModChainWithBuffer::calculateMonophonicModulationValues(int, int) + 257
4   com.hartinstruments.HISEStandalone	0x000000010de748be hise::ModulatorSynth::preVoiceRendering(int, int) + 62
5   com.hartinstruments.HISEStandalone	0x000000010de7448b hise::ModulatorSynth::renderNextBlockWithModulators(juce::AudioBuffer<float>&, hise::HiseEventBuffer const&) + 363
6   com.hartinstruments.HISEStandalone	0x000000010de7d13f hise::ModulatorSynthChain::renderNextBlockWithModulators(juce::AudioBuffer<float>&, hise::HiseEventBuffer const&) + 239
7   com.hartinstruments.HISEStandalone	0x000000010de7d13f hise::ModulatorSynthChain::renderNextBlockWithModulators(juce::AudioBuffer<float>&, hise::HiseEventBuffer const&) + 239
8   com.hartinstruments.HISEStandalone	0x000000010dde47a1 hise::MainController::processBlockCommon(juce::AudioBuffer<float>&, juce::MidiBuffer&) + 12017
9   com.hartinstruments.HISEStandalone	0x000000010ebad975 juce::AudioProcessorPlayer::audioDeviceIOCallback(float const**, int, float**, int, int) + 2421
10  com.hartinstruments.HISEStandalone	0x000000010eb2752d juce::AudioDeviceManager::CallbackHandler::audioDeviceIOCallback(float const**, int, float**, int, int) + 525
11  com.hartinstruments.HISEStandalone	0x000000010eb20ffa juce::CoreAudioClasses::CoreAudioInternal::audioIOProc(unsigned int, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) + 282
12  com.apple.audio.CoreAudio     	0x00007fff38fd8aaa invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 5639
13  com.apple.audio.CoreAudio     	0x00007fff3910bc22 HALB_IOThread::Entry(void*) + 72
14  libsystem_pthread.dylib       	0x00007fff73cb3109 _pthread_start + 148
15  libsystem_pthread.dylib       	0x00007fff73caeb8b thread_start + 15

HISE_CRASH.pdf

@Christoph-Hart Jumping on this a fair bit later... I'm having the same issue but in reverse. Getting immediate crashes when trying to load a project made in Windows (AMD again, but Ryzen 7), into an older iMac running Catalina on an i7... As far as I am aware I am running the same build of develop branch 2.1. Was there ever a simple fix for this or is it a bigger compatibility issue between my machines?

Thanks

@d-healey Ah perfect, thanks David!

Hi,

I'm trying to build HISE on Linux but something weird is happening with the projucer file inside the tools folder... It just doesn't respond at all to being clicked to open... I troubleshot this by downloading the projucer direct from JUCE and that's opening fine (but because the splashscreen is disabled etc... I can't use that version to build HISE at the moment).

So it seems to be an error with the build that I have from within the HISE folder. I grabbed the most recent DEV branch build 2.1.0. Which is the same one I have running fine on Windows.

Probably just doing something I shouldn't be, as usual! Just seems strange... Any thoughts? I am very new to Linux, but don't think I have missed anything massively obvious...

Additional info: I'm following your (@d-healey - thanking you) 'building HISE on Linux' vid and all going to plan before this...

@d-healey Ah, that's good enough for me! I didn't think 32bit would be a massively important thing to include in a release, but also see it's included in HISEs auto-generated inno script so wondered if people were generally still packaging it up... Thanks for confirming, I'll just leave 32bit out of it.

@d-healey Hi, would there be a reason only the VSTix64 compiles my end generally given my SDK folder structure posted above? For some reason x32 doesn't compile. It doesn't end in a fatal error, but rather just.. stops and gives the 'press any key to continue' command. Then nothing is outputted to the folder.

Any help always appreciated

@d-healey Just the one (develop). OK since your first comment, I went and deleted the vst and asio folders and unipped the sdk folder... No idea why, or how it made any difference, but it did! Just compiled successfully. I think I must have missed some updated docs on the sdk setup, I didn't realise they could ship with HISE hence why I discarded the included lot over the separated downloads... all good now, thanks as always!

@d-healey I had downloaded them when I installed the master branch so I copied them over when I built the develop branch and left the zip sdk alone. The folder looks like this (the vst export worked fine in master):

Could this be causing the issue?

Hi,

I'm getting the following error when trying to export a vst on develop branch. I can create standlone fine on develop, and I could also build vst's in the master branch before installing develop. The project I exported here is a new project to remove any possiblity it was something with my main project causing the issue. So this one is literally a sine wave generator and a keyboard to control it with. Still getting the issue:

I've made a video of the export too if it's useful, or maybe the above will suffice and I'm missing something obvious... Any lightbulbs?

Thanks

@d-healey Excellent, thanks for confirming! :thumbs_up_light_skin_tone:

@d-healey Ah I see, that is certainly doing the trick. I've also placed the NoteOff stuff in a for loop to cut down on lines of code as the stacks of chords grow, like this:

for (i = 0; i < eventIds.length; i++)
{
	Synth.noteOffByEventId(eventIds[i].getValue(n));
}

Or is this a bad idea as it's a loop within a real time callback? From an efficiency perspective, the chords I'm building a large tutti orchestrations, so I might have up to 10 elements to my eventIds array. Am I likely to create overheads by generating that amount of midiLists?

Thanks as always!

@d-healey Egg on my face... we're not out the woods yet. One follow up... How does this line:

'eventIds.setValue(n, Synth.playNote(n + 4, v));'

Become usable for 2 or more additional voices? I get hanging notes when simply duplicated. Assuming I can just wrap it in a for loop (in onNote and NoteOff) or does the initial declaration have to change? I'll start trouble shooting this myself now, but as I had replied already I thought I'd get this issue in there too so you're not replying endlessly to my Qs!

Thanks,

@d-healey Oh that is so beautifully simplistic! That single elegant solution has cleared up a handful of things in my head with working in HISE. Thanks David, you're a hero. Oh yep, well spotted, I did know the () on function call, I just wrote it like that accidently in the snippet direct on my post... silly me!
I think this is one of the final hurdles left on my first foray into porting one of my Kontakt libs into HISE to test the waters. I'm loving the workflow in HISE and really everything about it. It's so much more ergonomic and things seem much more intuitive (once the occasional new language hill is climbed).
Thanks again

Hi,

I'm currently trying to get a harmonised chord from single note performances, and am able to get the harmonisation I want, and even shut it off in onNoteOff when using Engine.allNotesOff. But it is causing an issue if you end up bumping two notes into each other in performance. I.e letting go of note1 just after having pressed note2 will result in Note2's harmonies and root being turned off too.
After quite some time reading and re-reading, then re-re-reading the handful of posts here regarding this, I get that I need to use noteOffFromEventId. I also get that I'll need to pass the eventId's into this via an array etc... and make them all artificial. I just can't get it to work properly, and I think I'm missing a simple fundamental. Can anyone jot down here, in the simplest form possible, the following pretty please? How would it look in it's most basic form (1 note triggering 2 pitches, with both being turned off on release. But without cutting off any notes that might have been pressed before the release of note1 comes...) Here's some of my assumptions, but I've tried many other variations on this, so this might not be representative of some of the versions I came up with that got a little closer... I'm loosing the will! thanks all.

oninit 

reg lastNote = []; //declare the arrays needed (this is my assumption, I've also tried this not as an array but rather just passing the Message.getNoteNumber as a variable)
reg eventId = []; //declare the arrays needed (this is my assumption)

onNote //how should this be handled and look in onNote? 

Message.ignoreEvent(true);

//I think from what I've read I need to make these all artificial with Message.makeArtificial() but I just can't get it there in terms of how the below needs to be written to do this job. 

Synth.playNote (Message.getNoteNumber, Message.getVelocity); // 1.play the actual triggered pitch
Synth.playNote (Message.getNoteNumber + 4, Message.getVelocity);// 2.play for example 4 semitones higher as a maj3rd harmony

lastNote = Message.getNoteNumber(); //send collect that stuff in an array/or variable I've tried both (this assumption)
eventId = Message.getEventId(); //send collect that stuff in an array once multiple notes are being triggered (this assumption)

onNoteOff //how should this be handled?

Message.ignoreEvent(true);

//this is where I have tried a huge amount variations on a theme, be it turning the lot off, or trying to selectively turn off the incoming notes with noteOffByEventId etc... to no avail...

//I assume I need to wrap it up in a for loop and call in the eventIds I just can't get it functioning and am completely lost. ```

@d-healey Cycle Markers (Cubase). With each mic on a separate track of course, but grouped in a folder, which incidentally doesn't allow you to group the folder without the samples being the same length. Then the cycle marker generated from the internal grouped samples. So each exported sample ends up the exact same length per pitch (at least I thought it did... maybe this isn't precise enough for this type of automated detection)...