YesThat makes sense. Just to clarify, is it still okay to drag samples in from the folder on my desktop, rather than using the files section on the left sidebar of the HISE interface, as long as I'm dragging from the Samples folder that's inside the Project folder on my desktop?
This is where HISE's tree structure falls down (currently). Groups have almost no routing. As you guessed you'll need to script this by turning modules on/off or adjusting their parameters. If it were possible to have more than one group active at a time (other than when using group FX) this could be really annoying.The one group issue I'm concerned about is that if I use the Round Robins to create all the necessary "groups" I'll need, can those RR "groups" each have their own volumes, envelopes and other settings? I'm assuming that would be accomplished through scripting (e.g. if RR Group 4, use Envelope 2 and mute all other envelopes)?
Yes, this modularity is one of the greatest things about HISE. You can have a bunch of little scripts instead of one massive script. And you can reuse your scripts easily in other projects. I have a bunch of little scripts I use often here. The largest script in your project will probably be your main interface script, generally you should avoid doing any MIDI processing in this script to keep all of the UI stuff out of the real-time thread, but as always there are exceptions and it depends on what you're doing.One other question - One thing that looks really appealing is that it appears that we can apply individual scripts to any of the elements of the instrument. Obviously that's nice that we can have that control, but what makes that even more appealing (to me, at least) is that these scripts can be individually placed where I use them, rather than in a giant master script. (The smaller I can make the master script, the better.)
Kind of. You can have global variables to share data between scripts. But there is no callback for when these variables change. Every script is also capable of accessing the controls of every other script, and this does trigger the accessed control's callback. With a combination of these two things and a bit of lateral thinking you should be able to have all the inter-script communication you need.So my question is - Is there a PGS equivalent so that these individual scripts can know what the master script is doing? For instance, in my wordbuilder example, can the master script tell an envelope script, "Hey, we're starting with an "s" instead of a "t", so make the Attack longer."?
My current project has loads of scripts that interact with each other. Sharing data through global variables and carrying out actions based on UI control values which are set by other scripts.