What is a sensible number of samplers in a single plugin?
-
@Orvillain Are you sure people want to do that? I don't see anyone going through the trouble of assigning 128 of anything. While I'm not familiar with your project, maybe keep everything the same for each layer. Personally, my goal is to always give the user fewer options — and make musical choices for them so it just sounds good.
I'm wondering – as this is a percussion device, how are you using timestretch? As far as I know, the algorithm also stretches transients (as opposed to leaving the transient, and stretching the release portion of the sound, like zPlane 3). You'd end up with mushy-sounding samples.
(And I obviously stand corrected on the choices issue.)
-
@clevername27 said in What is a sensible number of samplers in a single plugin?:
@Orvillain Are you sure people want to do that? I don't see anyone going through the trouble of assigning 128 of anything. While I'm not familiar with your project, maybe keep everything the same for each layer. Personally, my goal is to always give the user fewer options — and make musical choices for them so it just sounds good.
I'm wondering – as this is a percussion device, how are you using timestretch? As far as I know, the algorithm also stretches transients (as opposed to leaving the transient, and stretching the release portion of the sound, like zPlane 3). You'd end up with mushy-sounding samples.
Given that I used to work for FXpansion, yes I'm fairly sure people want to do that :beaming_face_with_smiling_eyes:
Absolutely possible that I am using HISE for an unintended purpose, but in the world of drum samplers, this is very common functionality - AKAI MPC is another bit of software that gives you distinct layers, and all of the associated envelopes, voice management, and routing options, on a per layer basis.
I'm just playing around right now, trying to discover the possibilities and the limits; trying to not have to jump into JUCE and C++ and learn both simultaneously, because really I just want to do some quick prototyping.
RE: Timestretch. You'd be surprised what people can be happy with. The timestretching on the old AKAI Sxxx samplers was horrible... but at the same time it helped pioneer an entire genre and aesthetic of warbly and mangled drum sounds! A lot of early 90's drum and bass used it to great effect!
-
@Orvillain Omg, that's awesome. Angus is a friend, and love catching up with him when I see him at NAMM. I was one fx's first endorsees, and love the brilliant work you folks did.
-
@clevername27 said in What is a sensible number of samplers in a single plugin?:
@Orvillain Omg, that's awesome. Angus is a friend, and love catching up with him when I see him at NAMM. I was one fx's first endorsees, and love the brilliant work you folks did.
Oh wicked! Yeah, Angus is a good friend too! I'm Drew (ex-FX QA manager, tech-support manager, BFD content developer - now with inMusic and BFD still!)
You reckon I'm trying to bend HISE to whims that it wasn't really intended for??
-
@Orvillain Dude I know you! I'm Bill Evans. Good to see you again.
I remember @Christoph-Hart talking about the maximum number of samplers being pretty high, but maybe not that high. There may be more efficient ways to do what you're aiming at than individual samplers, though I don't know what that might be. I'm hoping you stick around here, because you KNOW drum sampling!
You might be interested in my research, which converts acoustic drum performances to MIDI data. The MIDI is so close to the original that, when played back, it phase-cancels the original. (This also involves artifact-free stem separation, and the real-time rendering of theoretical sounds that weren't originally recorded.
-
haha!! Yes! Hi Bill, I definitely remember you. Definitely interested to see your research, feel free to pop it over.
I've switched from the full Sampler to the AudioLooper now... it seems to be a bit more stable here. I'll try that for now. As I say; just mucking around... trying out a few concepts. I've got some CMajor experiments on the go as well!
-
@Orvillain Here's a quick video…
The one also demonstrates the predictive audio to fill in parts of the recording that never happened, like if you pull two notes apart.
The technology, itself, is mostly physical modeling - but I've been using samples to demonstrate, because it's much faster to render in real-time.
You guys were the first people to make a believable sound drum machine. Geniuses, all around you folks.
-
Keep in mind that HISE has something like 256 internal MIDI channels.
If you then add a script envelope modulator (this is completely undocumented other than what you find on the forum here), you're now in the world of polyphonic modulation.
Then, use the MIDI node (with the default MPE set to on) to do any kind of modulation you want. Trigger it using CC. You'll have to call Synth.sendController in your UI controls, intercept it down the line in another MIDI processor and adjust its channel. This sounds like it'll be tricky.
But then you can use the channel-split controllers to communicate with your modulators. Controllers on each channel will only affect notes that were played on that channel. This sounds like it'll be quite the fun to set up and get working.
You can still use multiple samplers if you want like 8 engines, these can be separate samplers if for whatever reason something doesn't work. Already 40 is a bit crazy, will eat up memory and be a PAIN to manage.
@Christoph-Hart can you please give this a read and see if I hallucinated anything,,,, And do you think that there is an easier way to send a virtual polyphonic value (channel-based cc# value) to a polyphonic modulator than the current method of calling Synth.sendController() and intercepting it down the line because Synth.sendController() doesn't take MIDI channel as parameter?
-
@Orvillain Would love to check out what you're up to.
-
This sounds like an interesting path for exploration. But reading between the lines, this wouldn't give per-sample envelopes right? It might be a way to get per-voice envelopes, but that isn't quite the same thing no?
I have finished the night with my prototype up and running, in some sense. I don't know what I did, but my project started to compile much quicker after a while, and I have managed to have 128 samplers loaded up at once with no more stability problems. I'm perplexed.
@clevername27 - throw us a private message!
-
@Orvillain generally ----- 16 samplers is a point where HISE is comfortable, I once tried 32 samplers and HISE started to give up on me....but it depends on what's in each sampler..
HISE Development for hire.
www.channelrobot.com -
128 samplers is definitely overkill - the sampler module is designed for the purpose of streaming large sample sets so if you throw only a single one shot at it you’re definitely wasting a lot of resources (mostly RAM, take a look at your task manager after you created 128 instances)…
Loopers are a bit less resource-hungry but if you want to scale that with a good performance you should look into creating a custom sample player with scriptnode. I‘ve created a drum plugin with 36 individual channels like this and the performance is very close to the optimum (which would be handcoded c++).
-
@Christoph-Hart said in What is a sensible number of samplers in a single plugin?:
128 samplers is definitely overkill - the sampler module is designed for the purpose of streaming large sample sets so if you throw only a single one shot at it you’re definitely wasting a lot of resources (mostly RAM, take a look at your task manager after you created 128 instances)…
Loopers are a bit less resource-hungry but if you want to scale that with a good performance you should look into creating a custom sample player with scriptnode. I‘ve created a drum plugin with 36 individual channels like this and the performance is very close to the optimum (which would be handcoded c++).
Nice one, cheers! I've not looked at script node yet, guess I'll start digging into that this week.
-
Hmmm, So 128 ScriptNode Synths... each of them with a "file player" inside, gives about 500mb of RAM. Which isn't too bad I don't think.
Building my own node network for the kind of playback sampler I am looking for, seems viable.
-
@Orvillain that's a lot of RAM. Will users only load a single instance per project?
-
@d-healey said in What is a sensible number of samplers in a single plugin?:
@Orvillain that's a lot of RAM. Will users only load a single instance per project?
Well here an empty Groove Agent SE5 is coming in around 300mb by itself. I'd like to get that number down, sure. But 500mb is way more acceptable than the 3.2gb required to do this with the HISE Sampler.
-
@Orvillain yeah 300 is pretty chunky too. Do you really need 128?
-
16 pads x 8 layers.
I noticed one thing though. If I put 8 file players in a single ScriptNode instance (rather than having 128 ScriptNode instances), then that seems to bring down the memory. Still doing more testing, but 128 file_player nodes, is showing the entire HISE memory footprint of 105mb. Which is a marked improvement!
I just need to see if I can get the functionality from the HISE file_player. For instance, right now I cannot see a way to stop it from looping.
Promising stuff though.
-
How can I tell a specific instance of a file_player within a ScriptNode, to load a file from an absolute path??
More to the point - how can I iterate through properties and functions for the ScriptNode instance, from my Interface onInit method?
-
@Orvillain it depends on the type of property. Parameter sliders need to be connected to a container meta parameter and can then be accessed through the usual HISE attribute system.
Any complex data (table, slider packs, audio files) need to be registered as external data slot and then can be modified using the scripting API (just like you would load a file into the inbuilt loop player.
gives about 500mb of RAM
This is way too much but you should be able to bring this down by lowering the voice limit. If you have 128 instances, you don't need 256 voice polyphony so with 16 voices per sampler you can cut it down significantly.
