Architecture of a Guitar
-
@d-healey Thanks. I've no issue doing it efficiently in Kontakt, I was just wondering what would the most painless and scalable approach in HISE be.
I always found the limitation of 127 velocities to be very limiting. I understand why it's in the 25 year old Kontakt, but it really is an aged paradigm today, with the limit per map being only 127x128 samples.
I think there's potential for the Y axis to be open (or at least the limit raised), with a setting that says "Map velocity to Y", which would enable the current behavior of velocity triggering the samples for the first 127 rows. This then makes any similar architectural issues trivial as you can just dump it all into a single map, define the ranges in the script and properly script out any kind of behavior you want with all the samples being laid out nicely in a single sampler.
-
@Christoph-Hart I have Sus/Mute/Pwr/PwrMute with 8/16/4/4 RRs. Sus has 2 layers. In Kontakt all of these fit nicely in one group spread out over velocities, I then have 8 groups, with the script allowing correct group for playing the event note.
From what I gather, here I can either have one articulation per sampler, which ends up being 4 samplers, and I make use of the built-in RR/group system to put all round robins, with all strings being laid out in a single map.
Or I go with one sampler per string, which is the exact same layout I have in Kontakt, but then it's just the question of making sure each event goes to the correct sampler. What other way of doing this is there, other than the MIDI channel method you mentioned? What if there are more than 16 samplers, hypothetically? Is there no "allowSynth()" or something like that which could be called in the Container MIDI Processor? In Kontakt it's ignore event> disallow all groups > allow desired groups > execute artificial event.
I'm sure I can set up communication with the MIDI processors of individual samplers which would then either ignore or process the event, no? What would be the best solution for this? Global variable? Or is that too slow?
-
@aaronventure said in Architecture of a Guitar:
In Kontakt all of these fit nicely in one group spread out over velocities, I then have 8 groups, with the script allowing correct group for playing the event note.
Why not do that in HISE?
-
@aaronventure said in Architecture of a Guitar:
What other way of doing this is there, other than the MIDI channel method you mentioned? What if there are more than 16 samplers, hypothetically? Is there no "allowSynth()" or something like that which could be called in the Container MIDI Processor? In Kontakt it's ignore event> disallow all groups > allow desired groups > execute artificial event.
So you have an incoming event(note on) now you need to send it to the correct sampler... so you can;
- change its midi note (as Christoph said) and make each sampler react to only one midi channel, so we are limited to only 16 samplers here...
or - have a "note generating midi processor" in each sampler, set the values you want in the processor and tell it to generate.. now you have unlimited samplers.. you can even let this processor manage articulations for you.
In both cases you need to manage note ons and offs...
- change its midi note (as Christoph said) and make each sampler react to only one midi channel, so we are limited to only 16 samplers here...
-
-
@aaronventure said in Architecture of a Guitar:
@Lindon Thanks. Setting values would be done by creating a control in each processor, and setting its value from the main container processor, right?
yep
- never used Global Cables (yet)...
HISE Development for hire.
www.channelrobot.com -
What if there are more than 16 samplers
You have 256 MIDI channels inside HISE - you're welcome :)
-
@Christoph-Hart Hah, great. I don't think I'll ever need 256 samplers, so that settles it, I guess.
Re: global cables, I'm trying to wrap my head around it but there's only one thread on the forum and nothing in the hise_tutorial repo. Correct me if I got this wrong:
I create the cable wherever by first calling GlobalRoutingManager.getCable(id). I can then get a reference to that same cable from anywhere else by calling that same method. GlobalCable.registerCallback then registers a function for the cable change, but for that processor only, right? So each processor can have its callback for whenever the cable's value gets changed.
-
@aaronventure yes, but in this case I would not use global cables but stick to the message type that is already being passed around: the MIDI message (or its internal representation).
think of it this way: you have a central post office (your main script that calculates the string) and multiple smaller post offices (your samplers). Now if the packages they send between each other are completely self contained and all information they need to process the package is slapped onto the package with a sticker, they don't have to talk at all and everything is smooth and nothing can go wrong. A global cable in this case would be the equivalent of the central post office having to call the smaller offices and tell them: "the next package you're about to receive is for post office #3", then hope for the best that this information will receive the target on time and not get stuck somewhere along the way.
The prime use case for global cables is to send a modulation signal (or whatever) back to the UI or distribute an UI event to different targets, but if you can get by with only using midi messages for communication you should be good.
-
@Christoph-Hart Agreed, and thanks for the clarification!
-
@Christoph-Hart said in Architecture of a Guitar:
You have 256 MIDI channels inside HISE - you're welcome :)
Reply
How does this work, exactly? Message.setChannel says it can take only 1-16).
