@lalalandsynth I think I have found away around it. Although there are some warnings in the code about memory usage etc.

But since we are just using the plugins for MIDI and the only audio we are processing is are 2 audio paths from ScriptNode I "hope" it will slide.

Just add this the the Extra Definitions in the HISE settings will give you some extra breathing room for the plugin.

HISE_MAX_PROCESSING_BLOCKSIZE=2048

@Christoph-Hart This completely eliminates the jasserts in Debug and I can no longer get HISE to crash in Release.

I really appreciate the fast response.

Thank you.

@d-healey said in Still problems with Message.sendToMidiOut();:

@Christoph-Hart @ulrik @ps MIDI out doesn't appear to be working here.

I made an incredibly simple snippet. Just click the on screen keyboard.

You snippet works fine for me after I have added a few settings

and

Notice how you have to add a new channel in Ableton Live to grab the midi out of the plugin.
Explained here

@ulrik More updates.

If you like to use modulators and MIDI I have found the least changes you can do to the HISE code to make that happen.

diff --git a/hi_core/hi_core/MainController.cpp b/hi_core/hi_core/MainController.cpp
index 2863465c6..5a40b119e 100644
--- a/hi_core/hi_core/MainController.cpp
+++ b/hi_core/hi_core/MainController.cpp
@@ -975,7 +975,7 @@ void MainController::processBlockCommon(AudioSampleBuffer &buffer, MidiBuffer &m
                }
     }

-#elif HISE_MIDIFX_PLUGIN
+#elif defined(HISE_MIDIFX_PLUGIN) || defined(ALLOW_MIDI_OUTPUT)

        synthChain->processHiseEventBuffer(masterEventBuffer, numSamplesThisBlock);

@@ -1149,7 +1149,9 @@ void MainController::processBlockCommon(AudioSampleBuffer &buffer, MidiBuffer &m
 #endif

 #if !HISE_MIDIFX_PLUGIN
+       #if !ALLOW_MIDI_OUT
        midiMessages.clear();
+       #endif
 #endif

 }

Then I added the following extra definitions

JucePlugin_ProducesMidiOutput=1
JucePlugin_IsMidiEffect=1
ENABLE_ALL_PEAK_METERS=1 
ALLOW_MIDI_OUT=1

Export the plugin as a FX (not as MIDIFX) and Bob is your uncle.

@ulrik Did you know of this little quirky setup needed for Ableton Live MIDI output, because I did not. My VST2 from HISE on windows work fine both in Ableton Live and Reaper.

Just a moment...

(help.ableton.com)

@d-healey said in Still problems with Message.sendToMidiOut();:

@ulrik Did you try changing Message.sendToMidiOut() to m.sendToMidiOut()?

I did try to use the Engine.createMessageHolder() method but with no luck. What I ended up doing was to just use the Synth.addNoteOn|NoteOff|Controller() and making a child script that had the Message.sendToMidiOut() in both onNoteOn() and onNoteOff() and onController() callbacks which would take all the Synth.add... events and pass them to the midi output.

What it looked like if I added it to your setup.

There shouldn't be any issue with this, it's all happening on the UI thread (and I've been using it in a lot of projects :) ). There was a post a while ago from Christoph that warned against using external data in LAF functions, not sure if this also applied to local LAF. I'll see if I can find the thread.

Edit: Here it is - https://forum.hise.audio/topic/3228/look-and-feel-toggle-buttons-and-the-midi-sources-panel/26?_=1671280536688

I know I am confusing the LAF for buttons draw functions and the setPaintRoutine() for panels, I know local LAF functions would not have access to the data object and this like the ScriptPanel functions have.

If I could access the data object in a LAF call that would also mean I wouldn't have to use external data, like he warns in this post.

This isn't necessary, let's keep our designers out of the code :)

@lalalandsynth straight from the horses mouth

@d-healey I already agreed with you, no need to take me to school. :)

In my case I would just need to have object one level deeper with a list of on and off state.

g.fillPath(Paths.icons[obj.text][obj.value], obj.area);

And I agree, it is an elegant solution.
My mind is just already committed on the data object.

@d-healey That is clever, thanks for this.

I still think the data thing is valid :)

@lalalandsynth I think I have found away around it. Although there are some warnings in the code about memory usage etc.

But since we are just using the plugins for MIDI and the only audio we are processing is are 2 audio paths from ScriptNode I "hope" it will slide.

Just add this the the Extra Definitions in the HISE settings will give you some extra breathing room for the plugin.

HISE_MAX_PROCESSING_BLOCKSIZE=2048

There shouldn't be any issue with this, it's all happening on the UI thread (and I've been using it in a lot of projects :) ). There was a post a while ago from Christoph that warned against using external data in LAF functions, not sure if this also applied to local LAF. I'll see if I can find the thread.

Edit: Here it is - https://forum.hise.audio/topic/3228/look-and-feel-toggle-buttons-and-the-midi-sources-panel/26?_=1671280536688

I know I am confusing the LAF for buttons draw functions and the setPaintRoutine() for panels, I know local LAF functions would not have access to the data object and this like the ScriptPanel functions have.

If I could access the data object in a LAF call that would also mean I wouldn't have to use external data, like he warns in this post.

This isn't necessary, let's keep our designers out of the code :)

@lalalandsynth straight from the horses mouth

You can use the text property for all kinds of magic. For example you could put on icon,off icon and in your laf function you can check if , appears in the text and if it does you convert the text to an array using join and now you can use the button's value to get the correct icon name.

String parsing in every draw call ?
Now you are just asking for bugs :)

@d-healey I already agreed with you, no need to take me to school. :)

In my case I would just need to have object one level deeper with a list of on and off state.

g.fillPath(Paths.icons[obj.text][obj.value], obj.area);

And I agree, it is an elegant solution.
My mind is just already committed on the data object.

@d-healey That is clever, thanks for this.

I still think the data thing is valid :)

@d-healey that is absolutely true, I could make a separate local LAF object for each item I want to style. But I was thinking more in the spirit of data driven programming.

Lets image I'm making a toolbar of 20 buttons and I want each to have two separate SVG paths for the on and the off state for each of my buttons, 40 different SVGs.

LAF method: Make 20 local LAF objects, overwrite drawToggleButton 20 times, copy paste the same code only to change 2 variables in each function. Apply the LAF object to 20 Buttons.

Method 2: Make one LAF object, register one LAF function. Create a list of objects that contains the name of the button and both the SVG data variables needed for the button. Loop through the list of buttons, create paths from the variables, slap them to the data object and add the LAF object to the button in loop.

One is more verbose than other. Sure you can extract the functionality of your LAF function to a different function you pass the SVG data into as separate function parameters, but you would still have to write laf.registerFunction() 20 times.

Non coders would find it easier to come into a project, having only to edit a list that has a pretty straight forward structure, I would argue to it would be more of a learning curve to explain to them, find these functions, and change these two function parameters here.

I find the data object on the ScriptPanel extremely useful. It is especially useful to pass information into components for LAF styling.
My preferred way of working is having all the components positions and layout not be in code, so that a non coder designer can design and layout the plug without having to shuffle around pixel values in a list somewhere. That way I can just loop through a list of control IDs data structure that contains all the information for how a control should be styled.

I wish that the data object would be available for all objects that inherit from ScriptComponent and I could easily do that change and make a PR if other people would find it as useful as I would.

Surely it would create some memory footprint, and I have no idea how much a new DynamicObject on everything would add, but assuming it is empty for most cases I think it would be minimal.

What do you think, would any one else use it ?

Alternatively, does anyone has other ideas for passing data into LAFs without changing HISE source code ?

@Christoph-Hart This completely eliminates the jasserts in Debug and I can no longer get HISE to crash in Release.

I really appreciate the fast response.

Thank you.

@Christoph-Hart Excellent