Pretty sure this is some of what I'm experiencing here?

https://forum.hise.audio/topic/3388/how-do-you-set-a-vst-au-parameter-from-a-script-and-automate

Hello all,

I've been working on this problem for a while, I'd love to get some help if anyone has answers. I have some internal parameters used by my HISE scripts that need to be automatable in a plugin host. The values are stored in scriptSliders. They are linked to parameters in the VST/AU, but not to any module/scriptNode attribute. Their values change after incoming Note/CC values are received by the device, but the CC values are not statically mapped via midi-learn in HISE, because the control definitions need to be dynamically allocated depending on the mode the device is in.

Here's what I've observed so far:

• Changing the GUI scriptSlider's value in the main interface also changes the linked AU/VST parameter value.
• After linking a CC to the scriptSlider via learn in HISE, it is possible to change the value of both the scriptSlider in the main interface, and the linked AU/VST parameter, when the linked CC is received by the compiled AU/VST in the host.
• Changing the scriptSlider's value via a script DOESN'T updated the parameter value in the AU/VST, no matter what I've tried.
• Changing the AU parameter via the scriptSlider in the main interface DOES NOT trigger any automation recording into the host (checked with Ableton Live and Bitwig Studio, but I suspect it is the same in other hosts). This works in the VST correctly, provided that the parameter is the linked to a scriptSlider that is targeting a module's attribute.

So, my questions are, how can I:

• update the VST/AU parameter value from a script.
• get changes made in the UI or script of HISE to update the host for automation purposes?

Any help is greatly appreciated. I've been banging my head against this wall for a while. Here's a test patch with some simple methods I've been using to test with. I've looked around quite a bit for posts about these issues and haven't found anything relevant, but maybe I missed something?

Here's a test project demonstrating what I mean....you'll have to compile it and run it in a host to see what I'm talking about though. Ideally, using the "cycle" button in the UI should cause the VST/AU parameter to change just like it does the linked scriptSlider. In addition, sending CC9 on Chan1 will update both the scriptSlider and the VST/Param as one would expect.....but it still doesn't trigger any automation changes if the host is looking for changes in record mode.

HiseSnippet 1181.3ocsWslaaaDDdoroajZcQCPN.DAnvTUJtT1tIE0vvJV9ADRkiPkiQ+WvJxURK7pcIVtzwpF9e87j6ROB8FzaP6rbIEojkeDUX5eXMu14aFNyNC6JE9jnHgDYU9rIgDj02X2aBWMp0HLkiZeHx56r6hk3wDEQdFIRsM5fIg3nHR.xxZkSzZYUdUTxy+r+AXFl6SxYgPmKn9jekNlpx41s46nL1w3.xYzwEzdmls8E7VBlHFPzJ1dnPr+E3gjSwZ0JYirV6n.pRH6ovJRDxZ0CDAS5MR7ItQ+yoQz9LhlnApGbPF1GKXAZDq4hZMhxB5lE4QH3T5lmGVwjGdgcGZ.cJ+h4Cs.mbKJlOrJcevqwCCOuEAOqBvaUC7dtcOeIMTkKQis0r6ngYQDYTCU5YqY2RvUDtZyw3KHGKAh1.sb.1m3tsmW8s77pt65UbVuhjLzgKTjSiG2mH20vveDlyIro7R0qOleQad.4Jm8b7LrgWgQJmKwRGcAy63h9frLmOjnZIFGJ3.g6KyT3kZOq+ixYTNwYPL2WQEbGAOSE8AHELW+LqqCtfESptdkqA2BOfFQBFYyPIEN6Ml57MpYTbWiZEQbhfeXGPxMI.3gP4lQZAI.oElw5CUmt2BhlXY9HwmgGG5BNrtCST2YDsZJrkDUrj6zAqFs4XJ207C7UY5VMQYMDuqTTqI9LxCmeVPNBBGEkadKtgSMCFySPupQcGu5NaW8G2IK6oexhWc13bsObcKXTMmFU+9clyj47qRRGNjH0tVWWMjrwBOeir.2pOvKnjDvc81oX1QePERbmBE4um6Vsx0I9NulGJM5.sUvMOZOc5T9tYvbltgY0tkQzTUmKz6zsMOLV8KPYYt+psAPNyYlYMcfatZ6sWipO8uLukgNK1x++uS0Btw7OBKhLevt0xGr0V1fs1SavV4lJNyW.NXPREX44jkVxxzUcKPrdxo79LzkmjFytFHSQXDxrynrebyn7McdETTvayop2GR320fUTZ6JLCqTJp.UUISv91zIX8Xz.hDQgoUUryRbnDLmtXfymO4u1GcW1ePrRI3I1+U1I85yXr44CsODqv5QooHBPYHQpn5Df0gjKgcTLCVKaeHI5BkHLAxo2v.SVeLf9pbe1n4jbh2zjF0kEOjxmtJE30RgyxxriSgiCUv+q9fAcAm+5hN+CMQ2d8AXIFQPLCqlcyF85boBfRoY1iPuq.OhplTbcuuf0c7dzai8Xg6ys6RU9iVLdKs.7pqBehwa5xiqaezfADeUNXW093eeY2T7K.J+lHVeqHrBgjBED1vMo8fco8IoCkzs6VkzMlFZOMsNyzivCRH9W3IUXCMsUpvFYBQiw9RwG8Msi50SeVBG.S7jJ3xvRn.sSir9PaauM8Pigsl+nuuNU7J.6K1lsVBa1dIrYmkvleZIr40KgMuYIr4muWazevxaiUhwl1jzaAMyVPVecQBaqxyVQm9IEItIYBYVc.T3JUEatNhGT7tgiiYraoil4b506BxmJRm7QIPzn4c8K97I+8e7m6+VETO2OVM68is4WBWgaZmPc5dTxU7VVGwwPiig6+M9.jDK

I've been struggling with this problem since I wrote this post originally. I came up with a solution, basically to rearrange my scripts so that the CC reception was in its own script. It had been in the main interface script, since the CC's were controlling scriptSliders that were attached to module attributes. I moved the CC receive functions to their own script, and used setAttribute to target the sliders in the main interface script. Just chiming in here to let anyone that comes across this know how the problem was solved.

Now I have some other problems. It seems impossible to set a AU/VST parameter directly from the script by this method. Sending a value to the linked scriptSlider causes a change to it, and it's linked attribute, but doesn't change the VST/AU parameter value in the host. I'll make a separate post for that problem, though.

Hey all,

I'm at a loss to figure out a way to update an exposed parameter value in a VST/AU (a HISE parameter with the isPluginParameter enabled) from a script.

In my compiled plugin:

My parameters show up in the plugins device view, and I can change the internal HISE parameter by changing the value in the plugins generic GUI in the host.

Any control widgets (e.g. ScriptSlider) I have in the HISE GUI for the plugin that are linked to parameters with isPluginParameter enabled are capable of changing the internal HISE parameter as well as updating the value in the generic GUI in the host.

I can use MIDI assignment in HISE's editor to link MIDI controllers to the controls in HISE's GUI (e.g. ScriptSlider) and the incoming CC's change the internal parameter, the HISE GUI object (e.g. ScriptSlider), and the value in the Host's generic GUI.

However, when I use a script to intercept the CC's and forward them to the ScriptSliders or their targets, everything works (HISE control updates, internal parameter updates) except for the update to the Host's generic GUI for the linked parameter. Furthermore, having isPluginParameter enabled for a HISE internal prevents the CC from being received in the script and updating its targets unless the HISE GUI window is open. (when it's open, things work ALMOST as expected with the exceptions noted above....when it's not open, no CC initiated changes get through via the script).

I've tried scripting to the ScriptSliders that are connected to the internal parameters as well as to the target parameters themselves, and neither updates the stored value in the Host's plugin window. I've also tried with both a deferred script and a non-deferred one, with no apparent difference.

Can anyone else confirm this? Is this expected behavior? Seems a bit screwy.

I can work around this for most situations and use the internal CC mapping capabilities for what I need, but there are a few parameters that need to be stored with the plugin instance in a project that aren't connected to an parameter, but instead just stored in a ScriptSlider and updated via the script. Is there another way I could do this? Am I missing something here?

Thanks for looking, cheers :)

a

FWIW I get the exact same behavior in my projects in the scriptnode version with the AU/VST version of the editor.

It did work for me....after many tries to get the right combination of version + modifications to give me the features I needed.

In what sense do you mean, "does it work for modulators and lfos"?

All I'm using it for at the moment is to get the playing state of the host software, so that I can play/sync or stop MidiPlayer sequences based on what the host is doing.

FWIW, using a shortcut in the global Plugins library that points to the local library's copies of the plugins seems to solve my problem for now, but it still would be nice to be able to set this as a variable in the project settings somehow.

Hey guys,

This has been bugging me for a while. I assumed I'd stumble across an answer, but so far no luck.

My problem is simply that when compiling AU/VST via the export command in HISE editor, they are placed inside my local audio library: ~/Library/Audio/Plugins/*

I want them in the global library: Library/Audio/Plugins/*

Is there a way to change HISE settings so this happens automatically each time I compile? I can't seem to find it anywhere....and I'm wasting tons of time moving them manually.

Thanks in advance!

a

<insert gif of snoopy dancing>

I am in your debt, thanks soooo much for the quick reply! That solved it :)

Also, I appreciate the explanation about deferal....I suspected something like that was going on, but am still getting my feet wet here so every little bit of information helps!

a

I've got a project that builds and works fine in the release version of HISE. However, I need the improvements made to the MIDIPlayer import mechanism that were introduced in the scriptnode version back at the beginning of August (allowing import of non-960ppq midi files correctly), so I've compiled several different commits of the HISE au/vst plugins to make use of the changes. It's literally the ONLY reason I need the scriptnode version.

Now, though, when using the au/vst builds (any of the more recent ones), if I have any scripts that aren't deferred, I get a continuous stream of errors in the console any time the transport is running in the host:

Deferring the scripts prevents the errors from occurring, however it causes errors when processing any Messages (HISE complains, for instance, that I can't Message.ignoreEvent(true) because the message is not being processed in the MIDI callback...except it IS). So I'm at an impasse.

I have none of these issues with the release version.

I've contemplated (and attempted) backporting the changes from the MidiPlayer.cpp, but there's a fair amount of additional code added to the the scriptnode version of those files, so it's not such a simple task. There are obviously some dependencies and variables that are required for the newer version that aren't present in the release version.

Any ideas? I'm stumped.

a

For some reason, I couldn't get this to work before. I tried recompiling everything, and now it appears to be working for me. Go figure :/

I'll report back after I've had a while to do some testing and make sure it works correctly. Currently, all I've confirmed is that isPlaying() seems to report transport state correctly.

a

Hey guys,

I was searching for a way to sync HISE to the host's playhead and came upon a post about modifying HISE source to un-comment some lines used for accomplishing this sort of thing in the hi-core main.cpp module. (originally from post: https://forum.hise.audio/topic/2307/the-things-we-all-want-to-see-in-hise-3-0/18).

void MainController::storePlayheadIntoDynamicObject(AudioPlayHead::CurrentPositionInfo &/*newPosition*/)
{
	//static const Identifier bpmId("bpm");
	//static const Identifier timeSigNumerator("timeSigNumerator");
	//static const Identifier timeSigDenominator("timeSigDenominator");
	//static const Identifier timeInSamples("timeInSamples");
	//static const Identifier timeInSeconds("timeInSeconds");
	//static const Identifier editOriginTime("editOriginTime");
	//static const Identifier ppqPosition("ppqPosition");
	//static const Identifier ppqPositionOfLastBarStart("ppqPositionOfLastBarStart");
	//static const Identifier frameRate("frameRate");
	//static const Identifier isPlaying("isPlaying");
	//static const Identifier isRecording("isRecording");
	//static const Identifier ppqLoopStart("ppqLoopStart");
	//static const Identifier ppqLoopEnd("ppqLoopEnd");
	//static const Identifier isLooping("isLooping");

	//ScopedLock sl(getLock());

	//hostInfo->setProperty(bpmId, newPosition.bpm);
	//hostInfo->setProperty(timeSigNumerator, newPosition.timeSigNumerator);
	//hostInfo->setProperty(timeSigDenominator, newPosition.timeSigDenominator);
	//hostInfo->setProperty(timeInSamples, newPosition.timeInSamples);
	//hostInfo->setProperty(timeInSeconds, newPosition.timeInSeconds);
	//hostInfo->setProperty(editOriginTime, newPosition.editOriginTime);
	//hostInfo->setProperty(ppqPosition, newPosition.ppqPosition);
	//hostInfo->setProperty(ppqPositionOfLastBarStart, newPosition.ppqPositionOfLastBarStart);
	//hostInfo->setProperty(frameRate, newPosition.frameRate);
	//hostInfo->setProperty(isPlaying, newPosition.isPlaying);
	//hostInfo->setProperty(isRecording, newPosition.isRecording);
	//hostInfo->setProperty(ppqLoopStart, newPosition.ppqLoopStart);
	//hostInfo->setProperty(ppqLoopEnd, newPosition.ppqLoopEnd);
	//hostInfo->setProperty(isLooping, newPosition.isLooping);
}

I made these specific changes, recompiled HISE without issue, and tested things out, but I've been unable to get this to work. I always get "undefined" as a result of calling Engine.getPlayhead().isPlaying, for instance (I've tried all the available functions though, and have uncommented them all). I've made these experiments in the AU/VST versions of HISE running inside Live, Logic, and Bitwig.

I looked around for other variables in the HISE code that could be preventing these features from working, but couldn't find anything obvious. Am I missing something obvious?

Having MIDI playback functionality without any transport sync is fairly useless for my purposes. Has anyone gotten this particular change to work, or is there another way I should be going about this?

Thanks in advance :)

a

Can any of you at least confirm that you got this working?

Hey guys,

I'm trying to get the Engine.getPlayhead() functions to work. I've recompiled successfully with the modified hi-core file, and can call for example Engine.getPlayhead().isPlaying from a script, but I get undefined as the return. I could really use playhead information, and it's kind of stopped me in my tracks at the moment until I can figure out if this is possible or not....

I've tried in Logic, BW, and Live, same result everywhere.

Thanks in advance

a

Awesome :) I haven't tried it out yet, but I'm sure that'll do it....thanks!! That solves some problems!

a

In the outer container, there are three buttons. The first one is meant to relay to the second two, which are connected to buttons in the sub-containers. Pressing any button except for the main "ResetAll" button has the desired effect, i.e. to reset the SliderPacks in the sub-containers. Try moving the slider packs ('Data') and then hitting the resetAll button....

Thanks for looking!

HiseSnippet 1287.3oc6Y80SabDDeOauTvEpBQ8s9xo7.XTnFaWRZqnQwfAprZfXESPU8kzi6Vauh618zdqAbi36R+nzOR8aP6r2+s4vwbIEgR8gvb6ryL6uY1cm4GPGA2j34wEHskNYjKAosLt6HlbPqAFTFp89HsuA+FhGQ1wPX3PjDwqnryor9mP7jn8F4Z34QrPZZE+YkAZKUB4+72ubOCaClIIQDBcJmZRdE0gJSj1o4uPssOzvhbB0Ik1a2rsIm0hayGBfqHtFx0v7bi9jiMTpU.izV3.KpjK5JMjDOjVo83Vi5NfeIKP+SodzyrIpA0QcAGEH9PtskBwp2QsFPss5DkD7PfS6jjRJFjR9Z7QTKZr7jTyi7mPOwhz4CsBSCd0yI7zRAuRAvaUbWSA0UlLiBaKiOBfYvLigqPQE5TDCIXOo9EFBc+s3css0egdKNSRXxp8IxVbGWNCFT4IQJ7jM1YkxSXmxBXsHh5S27D8lpWZLidoguWB9hxrAQ58FxLkTNSmyh.rRcA2thYja1DVR6gjMVo76WorN7DoYU3GmplpRMkiimJA1IZTOaMZLgFWGBvzKQHfZYXaeFbhtxMfZPTs0VF1d7M0ubvHcKNwistTWNf5oeIWb9K0CdmQtfHzgjjmtI3OhUU34lYCgZANg+aDA+l4gvr.r3dbaRUWAER0qGZRs0iBzs1xW80VK1AikuJecbbNd9ZxvMEVTtNi72GvhT6wGykjWyprQ42WdoxWWVexo50Ky4BW.ahHyoU0gDSyvJrgNmQDQIvHEgKjieiu7rci2L3rdJE4r1Lp70tj3wAQZjjZn3.Lsnj3JsT+vIC0RDcyxLnv6ePAmhgpCuI8K27Ugka1anTxYHJTToLN5HLxOk.UwWHplOZFreU7DGbhcSoOF2zHC27116aHMTERCCQHrcIBIUsgosO4BnCUPY0kv6S7NWxc8yAgm4g83YIKbERCq8LX4Fod4KCverKV3NjHtJF8+UuliRBk0Z5Fse0FL7w3DaBKv6F0vVM+WD33bBiFofwu6MavnwTgwM6hA8R4VCsMji2fUwpHbB3N3XMxZq1+7nxQoYcbG55VKytt0y55vLB2UwcnRyAYi2BYfW3b3+03MjCyJ3C50iXJS.aI7g+ZdIrjOnr3svvb4TGd+TPozcloTpU7ijBYVgrVoOSnPlQQkrHRVnvjDImNAtIH+opGeqFnlLjl2sPw6CyuaBlMia25iQjKCJf83hJJXReQscn+z16Pe5SinLodT.TYUWapEQrqrMyhbUE5l5TfSjRgqiXAN0LxTHFlhU3bpO2qTeJLCbNh5nMEdOgLFdbnwAmT5.6v9NXArOgjP6wZZfoVJIvu3c8mWM94Gao9ri+26lSdLElIdLQgTROeT0z870allEwhyRzk3plm0br9eCHz9CRU6tcSufaRN7grTxeTSGiT.ZwldRhaW5enxY35UqMmRw+enT7F9PIk0+HCofpXZe7PmtPKcSBfDFiX6otGUPcELXbM0XUloKgY4O3efmvIqGcoSMY8nIuizVZLm1xCRZKMlBsEzbZK2KzVlSZ4ycRKIk0dvQbo9mLhK+o4bhKyIt7vm3x8wZ3XXJ3uyLnVgp27h9Rf3l4+OmaI7Qpw5w+cbw3ZvIcGfxv6LMUo6uExOYaSibXy2kCa1NG17rbXyyygMeeNr4GlpMJ1Z6NTxcBtJBB5bfeANMsCXFvIY+S8n+E.KbOUr

@d-healey Thanks for the recommendation, but that's simply not an option in this case. Is it simply not possible to do this from scripting?

Here's another case where this paradigm simply doesn't work:

I'm trying to create a single button that can reset all sub-modules to their original, default state. This is convenient for development, but also will be necessary for the end user so they can reset certain aspects of the plugin after they've made possibly catastrophic or confusing accidental changes. My understanding is that there's no way to connect functions of a sub-script to a higher level script in order that they can be triggered by the main IF through to the subscripts. So, I've created button in a script processor of the main container. In addition, I've created reset buttons for each of my sub-containers in the main container, linked them via processorId/parameterId to buttons inside those sub-containers that trigger the reset functions (this is for resetting bank specific callback definitions, etc). If I press any of the individual reset buttons in the main container, they trigger the reset functions in their corresponding sub-container as they should. BUT, there seems to be no good way to create a "master button", have it's setControlCallback() trigger the buttons in that same container to call their siblings to call their corresponding sub-functions.

This is all very confusing to me. I understand that it's necessary to do things in HISE in a certain way, but some of this seems so "backwards"....any help is appreciated.

Hey all,

I'm curious what the "proper" way to script control of a widget in the interface that is controlling a module's parameter.

Here's the situation: in the main interface, I'm using mutliple instances of dial widgets to control different module parameters for effects and whatnot. In turn, I am scripting via onController() to set the values of those widgets based on input from MIDI data coming from a hardware controller.

Widgets are connected to their designated modulation targets via the processorId and parameterId in the property editor. When using the mouse to control the widgets, they work as expected. However, when scripting their value changes, their linked modulation targets are not changed.

Currently, I'm additionally forced to script value changes in onController() directly to the modulation targets in the modules themselves. But this seems inefficient, and is certainly undesirable from a readability standpoint. Is there a better way to do this?

Thanks for reading :)

a

--bump--