@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.
https://help.ableton.com/hc/en-us/articles/209070189-Accessing-the-MIDI-output-of-a-VST-plug-in
@d-healey said in Still problems with Message.sendToMidiOut();:
@ulrik Did you try changing
Message.sendToMidiOut()tom.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 :)
@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 ?
@d-healey said in Keep hitting walls, wouldn't mind some help or ideas.:
@jonhallur I'm not DanH :)
I apologize profusely.
WARNING, wall of text.
I have been trying to make a little plugin that can take the modulators in HISE and send them out as a MIDI CC messages.
Sending MIDI out of HISE is possible when exporting your project as a MIDIFX plugin. Unfortunately when running as a MIDIFX plugin none of the modulators run, neither the Global Modulators or the scriptnode ones.
@d-healey mentioned in a thread that I could get the global modulators to work using the flag ENABLE_ALL_PEAK_METERS=1, but that meant that I had to use the FX plugin type instead of MIDIFX, which again meant no MIDI out.
So I ventured into the C++ code and hacked around in the processBlockCommon in HISE's MainController as detailed in this post where I could block HISE from clearing the MIDI buffer, so that you can create MIDI events using the JS code. But that meant maintaining my own fork of HISE develop branch which is not ideal.
Then @Christoph-Hart published the Message.sendToMidiOut() which I thought would be my savior, so I threw away my fork and continued to work on the now FX plugin, since I'm still dependant on Modulators and scriptnode.
I soon found out that, if I understood it correctly, that it was only meant to echo/modify the MIDI input back out to the MIDI buffer and I could not add any CC values anywhere, as doing so outside of the onController() callback it will generate an error in the JS output log. In my context I'm not expecting any CC input into the plugin, so the callback would be a useless place for me to generate my CC.
But I realized that I could use/abuse the sendToMidiOut() function he added to the MainController to do exactly what I wanted to do, but I had to do that in C++ which is fine.
So I added a floating tile with it's own C++ code as describe in the ExternalFloatingTile tutorial which, yet again worked like a charm. I could have my own timer in C++ where I could add any MIDI message I wanted and for a while it was beautiful, I thought I had cracked the problem, right until I tried to close down the Plugin UI inside my DAW. You see, when the UI is not visible, HISE calls the destructor of my C++ floating tile and for my poor plugin to work I now have to make sure it is visible somewhere on the screen at all times.
So now my options is to go back to maintaining a fork, blocking the clearing of the MIDI buffer, unless someone has the silver bullet that will save me. I would really appreciate any ideas if anyone of you have any.
Sorry for the long post.
@ulrik No, I did not mess with the ProJucer project file at all it's just settings in HISE.
I also did not compile the HISE Standalone editor again, if that is what you mean.
@ulrik With out knowing it completely, I don't think under the VST2 or even VST3 (I´ve done some professional JUCE work before using VST3) there is no concept of a MIDI FX plugin.
At least in JUCE, you just tell the host that you want to receive and/or send MIDI. You can do the same with sound, stating how many channels you want to input/output etc.
I have no idea what a given host does with that information. The host will ask a plugin upon instantiation weather it will produce audio and/or MIDI. A JUCE plugin can answer yes to both. Perhaps some hosts will decide to put some plugins into some categories, but it works on Windows both in Reaper and Ableton Live
I encountered a crash when manipulating table data objects. I'm using Table.getTablePointsAsArray and Table.setTablePointsFromArray functions to mirror (and manipulate data, not used in this example as the crash happens without it) data from one table to another.
I'm doing this from the Table.setContentCallback since I want this to happen when I "add, remove or change" a point in the table.
The crash does not happen instantly, but pretty reliably when using the right-click mouse button to change the curve value of the adjacent table point. (I'm pretty sure I have experienced a crash with a left-click and move on a point in the table, but very sure about the right-click.)
The crash happens more often/faster in a compiled plugin running in a DAW.
These crashes are happening on the develop branch and have not been tested on master.
To recreate the crash one should only have to play around with the table for a few minutes, and be liberal with moving the mouse all over the place while holding in the right-click button on the table to change the curve value.
A side note, when using the script node example, when running the table using a clock ramp, the setContentCallback is called repeatedly without changing any points in the table.
ScriptNode example
HiseSnippet 1583.3ocuX01SabDDdOCaRsaPpos46mxGhLpTGbdgRTTSwXfDqV.qXGZT+BZ4t01q37tW2aMfSUj5Os9Sp+CRmY2y9tCrID2zZjPd24smc1YlmEZqUA7jDkl3Ut63XNw6NzNiklAMGvDRRqcHd2iZXmDwONPyRFbL+B1v3HNY6wwrjDdHwyaoWhp5UdYh8ye+SayhXx.d1VDxQJQ.+WDCElrcau0OKhh1iEx6JFlS6mrUq.kroJRMBf0Rz0IwrfSY84GvP0JQId2Z2PgQo6XXFdBwa4sUgi6LPctzo+QhDA.YbQcRGvQts2SEEhHF2kzbfHJr8jieBA7R6rjwRtjw2R2WDJlteVR4qrB7yrHe9vqTQ3sTA3UOO7VOG7lAj7xAIpCR2k1IPKhMYRP77Mo6lgn5EfzAiF1EuEAzP89RHI6TmT5CknMURCWZpMjcJeOMrnErV2iEvqtw5qulO7qUetekJvkRhw+Ll12Y7dust+O5aqVp0mar9eZ3qd+T.AZc+UedNi6OPkXN1VSAlOI3fCZpFFqjvhp2OmNEM1UJFxLLv1ck8ERds.MGxyMjgul2Wj.P2hjc.cpVGPdkJngIVzHUg7ogd5oXJ5qhpmK10z7df6TVekEZzmUd3C8+0AbYNG6KR7CFvPP022LfC.NZD2W0ytvE0yDL+fHUvo9ZnOBcBJKvkD7CXQQm.059mCMF9m3DHjiTiRhFaWCJvCqUwuxkOO0RvDn0MMS8R0dijAFgRVcU++nRYLKvzZ3feEamd6oDRSRijFZMabU3XVVzqJZyCd.ZZsHtruYf+K7quZkxkyRHXvy4.nHZnyEfQfWd+pOeBT7UxCTF9g.lp.Xpx6q3eYQ85MSY3gSqfiudlhwQH5qyvpxQCOgqWycqLUQnsuXyJc9Mq4mkjdkkSQkrkTXNLlKm2DFR5EDzXWJEUP3M115URafsoQh.ZZ+Z5kumHVnmerJl7IdOk93MpU7yYGd34Gb9yZ2+2e4lMabzSd2gvl89NTzyDA.pOzglqGBqPy0L7YN5uoE1Ugy3RyJPlJlqMB7RvaG9Y.ggahWY5N7jSMpXaZKcFAw61eBItKxf8K1ZbdplyEglAS2Xq+bqAbQ+A4XoDaEO4JrUnkdb5bMLE9wgSwj3bPxVweTj7W82x5hVxP9E3X7JVRzLBhkcoKfZRENJhYJxWgjzoBf9hBjC37dYhvLNOI9mMRraJDuKssvDLX1XrzLvH1F8e.FSo9Wgtaud7.SF.Wlt2a++imuBcB+jM3Ep6lKytWNl8eyi5mi3TyjIwJs4ULYHLD8xzmcujbb5+ULBmyuqDi1K0hvpF8H9Z9aNOMgWFD.2l7pWQXaKu5tW.b0RVzrs2vztGh.ZzDYLsjyYC1i07Xll2U0NBHZRruJ80vAYM+SPs6HdG+prAosxaa8GxUK4QIKBowstw270u9BuWqFAL782mYzBrqFtN6.u6Mf2LEc30ZIj6vsdcbMV62gKCsK9.7IUX8o0.fv5SDlQ6PNfaNWoO0Vxk9c3rf0Wqj+U9ji35DrCz61z0qA+PZDEoNGm1IR6MgJO6dsUQiiGnjh.bKmFSvdigpQ3nQ2A3UrjtLQD1LCAGpK.A6wBfr331Lbx2coHoJzsAW+AS65JBrrJeLehdYxemfKq..XncbL9WIrDJGOqkRCmqQx99qiw2eQtR70P+Pl3OonsLd3i3WLgVaGQRLTZt8HXLhqIuvNv5zI4KS+dfJoMCBI23TkNcE788ExibTuT71frO6hz02hVeSXiNFdLVuiJTGViGyaS6xAtIRAKIyys0ura2XNt8Nz8GEYDwQBvGELmbyfrS4Y45UnMBC6p5H5Cc72PbeS88cnuIFdsBGGGsfv9Qyw0UnsjPUj3L9kwb16YHjLVstLM7babubEkqPCrE4t2HTnp7d1tBXVTs7p7upxLkuXx2xpDsynJTH5kK8rzGKy6p6ba8wO94iSAssrg3Jfquj61qUxQnzfrBCXjxh7Bx+Wl2NjEnUGmdsgGnuvtCjAk1+CFko6iq8qO4I0tz4PQn33ffICDlsMOZAr4wKfMOYAr4oKfMar.17CKfMads1f+ybZLxnF5H2fMZuqs3xyy8dG6SsH+CrpkhQO
Example with no script node, just table data.
HiseSnippet 1759.3ocuX8+aaTCE2Wa8FMrhX7keAjPmlPSYrQZxFqLDBnsosPDzsrkrxWjPUt24jX5E6S9bZa.M9af+r3OG9O.dO66xcWZRoMLVpTUr86Ke7687yebZqUA7jDkl3sZ2wwbh2MncFKMCZNfIjjV6P7depTIOLIPKhMG16rCMrih3GFnYICHaONlkjvCIddK+0nBdqtBw94u9psYQLY.OeJB4.kHf+chgBS9rs27aEQQ6wB4cECKH8mrYq.kroJRMB.2xz5jXVvwr97GyPwVhR7t1tgBiR2wvL7Dh2JaqBG2Yf5ToS9CDIB.p3fFjNfgbSumJJDQLNKo4.QTX6rfPBArR67PxxtPx6P2WDJlLedn4MsK3mqQw3g2Rkg2xkfWihvqdA3MCH4U.RTGjtIsiMgjuBhm2Nc1bD0nDjd7ngcwrGfFp2qCAYm3jk94UnMURCWZpMjcLeOMLnELV2iEvqtQ852y+Q0qemO2uRk0WGRKIF+SXZem568CM7+BeaUSs9bi0CS.P0akBIPpacmOuRkbs6OPkXbkSf9Y9GrPS0vXkDFT8VEjA0NWYWU3oByfCCYF1bMvTxU1HwLMHTlA1U1WH40BzbHgskL7Y79hDHFX2P6.xT8gy.BWZkaTG29quNpp6zjTExmr+mDKmDCqhJTH.TSy6AFTYsVtyAglZSVRvB6Qz+EFVKAiT1fVSVTzQvwqp8FICLBkr5c7+sJqhPko0.5Jp1jbrRHMIakrkVyFWEL9phdUQwu8sQspEwk8MC7+R+F2oxpqlCXzuEL.TrMzYBPIvJuvEl7+9AbYg.kuHwOX.CCy88MC3PJHZD2W0yNvEEOQv7ChTAG6qYCiQifqE31i9AoaR+SgFN9G4VPHGoFkDM1NFDfGVqx5ejekoyPWkf04z8UQD6iVOCN9J4iUF9S.bUAvUkWTwe5k50alqgaPsBBB5YtL1fVeQJVUNZ3Qb88b4lIBBMUK2JjN+VgE6Tml3JHnR1RJLOIlKmW+aRZRBZatbJp.2arMMWKs8nMTRDPKw2hNcthXgdwKsvD.w6gzGrQsxeN4IO3gO842U9iQ+3FMsig+06t3RelarCMWLDViV3H9Ux6a7z9i+reY6uezmt3d+lzo5c7RFAOuE1DBuCKMu.4pXt1Hvx.uc3m.DBb2nsJcGdxwFULbu9j92DuqeERcmkC6vMGWjJwohPy.7Ru+viPFvE8GXvQ+IrXbVwSqvYeAJ4xflxYw4.jMiy.R1pi2LCLYyH1zZhVxP9YHDqPHWNDb9L47BG+9UGEzKFEeG6HdjEEuQwYZTDBe3bxHmQJlQdGXjgeF782i9b4Hf2RZ2Te6c.tv6UGI2uHR1YloDpWXIj7ASPBX6H1IKtyev7bddlX9N+Mn6yPdDYdu.UvUbGb.RnpvQQLSYloHc7zEfdzknAhL6jIBy3hz0eoQW8xBwaRaKLAClMFWZFXD5h7+AFSI4uFc2d83Alb.tBcue3UGi9JzLFfVmeCZNu44yg2q.G9exi5WfbplIShUZy2vjgvE5SSQs6TqirQNmRHuickn29ZsHrpQOhCODXdRBu.H.xl7pmaw1VBo6dFTGKYQyVeCS6dxAHQSjCmk9aNIiXMGIg1U0NBH9j.76h3OC1H2y+HT5NhekedlIoM221ZOj8njGkrHDXt1kNy23hK7dlZDv4r+9LiVfsVgzYG3EtA7lonCSqKgcaciqiiwZ+NbYncveCeRWrwjZ.XwFYKlSAh7Xt4Tk9XaIW52g8BVesFs363OfqSvSfdWmVuF7GYqnH0oXmNQ5YSnxyNWaUz33AJoH.mxIQF12ZnZjzjsA9FVRWlHBOLCNGpKfE1iE.QwwsYXSuaRQBdvoMH8GL4TWYfkW4iwSzJY+h.tnB.fg1Vw3uGvx353dcoT24NHYeQvg3KBHmy+Z37P9xWIusBt4i3mkQvYGQRLTZt8HnMh6PdoYfwoWmtB8iAVEsYfK4FmnzIifuuuPdfiDFEyFj8YmkN9ZzFOBlnigGi06n.Mfw3175ztb3dIRIMIyyrMl1raLGydC59ihLh3HAXiRpStbP1I7rL8ZzsBC6p5H5Cm3uj39xZ6aPedLvAhisiVPXe+4X5JzVRnJRbBeZLmyrkPxuUqKSCO+CmqPQ4Zz.aQt6R8RUkuq8TAzKpVQQ9OUYldeQ12xqDs8nJUH5UH7r7+Vj2U24l5ee6WzOkj1daHNBtqeIW1qUxA3pA4EFPKkE4sDuR52NjEnUGll1vMzqYmAhfR6uU4p.GNXreirGW4BmCEghCCBxZHLact+BnyCV.c9jEPmGt.5rwBnymt.57nKTG7mscqQF0P2kavDs20Vb44436XoZQ9GG6xcnC
@d-healey Right, I somehow missed that.
Thank you for your assistance.
The LAF function for drawPopupMenuBackground, even when left empty, draws a white square over obj.area
Expected would be nothing would be drawn and the background would would be displayed and popup menu items could be drawn over that background.