The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm
-
@Orvillain you can still do that. It just adds another layer on top of that so that you can implement more complex layouts more easily plus there are a few new functions that only work with this new mode.
-
@d-healey I have to check this as this is not something that I would brute force fix, but it should be pretty easy.
Can you send me a samplemap that crashes?
-
@Christoph-Hart Sounds great. I'm looking forward to docs + Dave's video!
-
@Christoph-Hart said in The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm:
Can you send me a samplemap that crashes?
https://codeberg.org/LibreWave/BellAndBone/src/branch/main/SampleMaps/trumpet_sustain.xml
It looks to me like the
group += 1is on the wrong side of the else. Because, from what I understand, it should happen when we're not using the complex group manager.Free HISE Bootcamp Full Course for beginners.
YouTube Channel - Public HISE tutorials
My Patreon - HISE tutorials -
@d-healey Alright that's fixed - that logic is a bit convoluted because as soon as something is not zero based (like the old RR group values were) it breaks my brain, but you can thank that deficiency of mine for not having to write Lua all day.
-
Hey - are there any good tutorials that can get a beginner into this complex group editing stuff???
-
@Orvillain it's not ready yet but we did get a mini tutorial in the last meet up, think it was in April. Video is on my YouTube channel
Free HISE Bootcamp Full Course for beginners.
YouTube Channel - Public HISE tutorials
My Patreon - HISE tutorials -
@d-healey Sorry, do you mean the feature isn't ready yet? I'll go and dig out the meet up video. I can join those in the future now I'm no longer at inMusic !!
-
@Orvillain Yeah the feature is in a kind of beta state - at least it was last time I checked.
Free HISE Bootcamp Full Course for beginners.
YouTube Channel - Public HISE tutorials
My Patreon - HISE tutorials -
Alright, let's continue the discussion here. I'll address a few points that David mentioned here
No apparent way to revert to the simple group editor after enabling the complex one.
yes, you somehow have to delete & recreate the sampler module, but this is just an intermediate state, ideally this will be stored with the samplemap at some point, but I haven't completely figured out the data model yet - there are up and downsides to storing the complex group information within the samplemap vs. as separate entity and this affects how to reset it obviously.
Workflow felt odd compared to the old system, as all samples appear in one big pool rather than in pre-defined groups.
Hmm, not sure how to "address" this, as this is the very core of the new system - have it all in one big fat list and add layers of organisation on top of it. You can click on any group button in a layer to only show the samples that match this group value (just like you can do with the old RR display in the top right), but maybe we need more fine-grained tools to control which samples to show / hide as I can imagine this gets tedious with large sample sets - maybe some kind of bookmark feature that allows you to quickly recall sample selections to show.
Exact purpose and use of the batch processor.
If you have multiple layers you can assign multiple tokens at once (this mimics the UX of the old file import dialog), also it gives you a console log of what happened. It's definitely a power user tool though and might not make it in the final version...
How to control crossfade via the GUI without scripting.
The inbuilt sources already offer quite some options for non-scriptable control:
-
MIDI CC
-
global modulators
-
event data (ok for this one you need at least one line of code that sends the value).
-
How multiple layers interact with each other in practice.
-
When or why to disable the cacheable or purgeable flags.
-
Purpose of the ignore flag beyond possibly scripting control.
These are covered in the doc section (after the nerdy bit stuff):
https://docs.hise.dev/glossary/complex-group-management.html#cache-groups-prefilter
But it might not be explained in the Best Way Possible (tm). One thing I was working on was a example project that created artificial samples (sines, triangles, saws) that covered / showcased all features / combinations which might offer a more hands-on experience, but that's not finished yet.
Why crossfade layers affected articulations that weren’t meant to be crossfaded.
That's precisely what the ignore flag is for - if you have samples that shouldn't be affected by this, you enable the ignore flag for the xfade layer and then assign all samples that shouldn't be faded to the ignore group. I'll check that this works real quick, might be possible that there's a regression already.
-
-
@Christoph-Hart I should probably read those docs!
Here's the video, sorry about the poor audio, I was testing a new mic configuration:
Free HISE Bootcamp Full Course for beginners.
YouTube Channel - Public HISE tutorials
My Patreon - HISE tutorials -
@d-healey alright nice, so my main takeaways from the video are:
-
unassigned vs. ignored is not self explanatory, so more labels / help popups to the rescue! Basically Unassigned means "BAD, CHANGE THAT" and "Ignored" is a valid state that you can assign to any sample that should not be affected by this layer (eg. if you have a single set of release trails that should not be affected by the XFade layer, you would enable the ignorable flag for this layer and ASSIGN all release layers to the ignore state for the Xfade layer.
-
the icon to show the tools that you use to assign samples (the second from the left on the top bar) makes no sense at all, so I'll probably replace it with a text button. I'm a bit irritated though why you struggled so much with the pen icon - that's an established HISE trope, smash the pen button, then the grid appears and you can edit stuff (interface designer, module tree, etc).
-
batch processor needs more guidance - basically you can use the "return key" of the batch processor to assign all layers at once and the text field (which is supposed to be read only) will print out a report on what has been assigned to which layer.
In the next iteration I've fixed the purge butttons not working and added the functionality for the release trigger logic - it does also detect & match the gain between the sustain & release trigger group just like when you use the release start feature. I need to test this in combination with some other layers though before pushing it though.
-
-
@Christoph-Hart said in The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm:
why you struggled so much with the pen icon
Yeah just me being dumb.
I think all my other questions are answered in the documentation :)
-
This post is deleted! -
I watched my last video back, and just thought I was confusing everything by having so many samples. So I did a new one:
I'm not sure if I am misunderstanding how this thing is supposed to work. But essentially... create 2 RR tokens... add a sample to group 1 and group 2 ... you get the correct RR cycling behaviour. Now create 3 RR tokens.... add a sample to group 1 and 2.... you end up with an empty sample being triggered.
I accept I could just be being a total silly face, but surely this isn't expected behaviour?
-
@Orvillain I'm ignoring all the UX suggestions and minor glitches as I'm completely unsatisfied with how it behaves at the moment and I will have to do a third or fourth complete redesign of the UI of this thing.
The only glitch I see in this video is that if you have more than 2 groups (eg. 5 or 8) it still only performs 3 groups - probably it knows that there is no sample in the last group and then it resets the counter, but I'm not sure why it does that.
But in general it's expected that you use as much RR groups as you have RR variations, so you're already in weirdo land if you use more RR groups than samples.
Now if you have different amounts of round robin variations within a single samplemap you can achieve this by using multiple RR layers - which is where this complex system starts to show its strength, for simple RR stuff you don't need that in the first place.
So let's assume you have closed hi hats and open hi hats in the same sample map. For closed hi hats you have 8 RR variations, but for the open hi hat you only have 6 RR variations. You cannot setup a single RR layer to work with both types, instead you need to create 2 RR layers:
- One for the closed hi hat samples with 8 groups
- One for the open hi hat samples with 6 groups
And then we assign the closed hi hat samples to be cycled by the first layer and the open ones by the second. Now comes the important part: in order to tell HISE which samples are subject to which layer you can use the Ignore flag (so in this case both layers need to have the ignore flag enabled). This works like this:
- Assign the closed hi hats to their respective group in the first layer
- Assign the open hi hats to their respective group in the second layer
- Assign all closed hi hat samples to the ignore group in the second layer
- Assign all open hi hat samples to the ignore group in the first layer.
Note that this idea can be combined with any layer so you can create very complex group arrangements. If only the UX would make it easier to understand that stuff...
-
@Christoph-Hart said in The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm:
@Orvillain I'm ignoring all the UX suggestions and minor glitches as I'm completely unsatisfied with how it behaves at the moment and I will have to do a third or fourth complete redesign of the UI of this thing.
The only glitch I see in this video is that if you have more than 2 groups (eg. 5 or 8) it still only performs 3 groups - probably it knows that there is no sample in the last group and then it resets the counter, but I'm not sure why it does that.
But in general it's expected that you use as much RR groups as you have RR variations, so you're already in weirdo land if you use more RR groups than samples.
Now if you have different amounts of round robin variations within a single samplemap you can achieve this by using multiple RR layers - which is where this complex system starts to show its strength, for simple RR stuff you don't need that in the first place.
So let's assume you have closed hi hats and open hi hats in the same sample map. For closed hi hats you have 8 RR variations, but for the open hi hat you only have 6 RR variations. You cannot setup a single RR layer to work with both types, instead you need to create 2 RR layers:
- One for the closed hi hat samples with 8 groups
- One for the open hi hat samples with 6 groups
And then we assign the closed hi hat samples to be cycled by the first layer and the open ones by the second. Now comes the important part: in order to tell HISE which samples are subject to which layer you can use the Ignore flag (so in this case both layers need to have the ignore flag enabled). This works like this:
- Assign the closed hi hats to their respective group in the first layer
- Assign the open hi hats to their respective group in the second layer
- Assign all closed hi hat samples to the ignore group in the second layer
- Assign all open hi hat samples to the ignore group in the first layer.
Note that this idea can be combined with any layer so you can create very complex group arrangements. If only the UX would make it easier to understand that stuff...
Okay, I think I get it. So hypothetical here:
A hihat with 20 articulations.
Each articulation has velocity ranges. For argument sake, let's say the velocity range is split into 10 for each articulation.
Each velocity range has a different number of RR layers. It isn't the case that each velocity split has the same number of RR's.So that means, a single hihat sample map will require 20x10 RR setups, each with its own number of groups.
Do I have that right?
In such a situation, yes, it would seem the existing UX is very much an issue. Especially considering that all samples need to also be in the ignore groups.
Personally, setting that kind of thing up, I'd rather script it than do a shed ton of mouse clicks; particularly when you consider a product might have 5-10 hihats, all with different recordings.
-
@Orvillain I think maybe my example was not the best one. The complex group system is only useful if you need something ... complex and if all you have is RR groups then you don't need it at all - in fact the normal RR system even has a function where it precalculates the number of RR groups for each velocity / note number and automatically wraps around that, which is a far more suitable solution for your use case.
The complex system is getting useful if you have to combine multiple things, eg. crossfade dynamic layers with RR groups or legato transitions with crossfade, etc.
-
Gotcha. Maybe I'm thinking about this all the wrong way, and the best approach for me is to use the classic method of handling all my RR logic inside a midi processor script.
I haven't got to implementing any of this yet. I'm still just thinking about it. But as I see it, and from experience, a hihat needs the following:
- Ability to trigger multiple articulations, with round robin functionality.
- Ability to fade out or "choke" earlier voices when a new voice of a different articulation is triggered (Open to closed)
- Ability to crossfade from one articulation to another, based on incoming midi CC (usually CC4)
- Some way to trigger the 'tail' of a 'more open' articulation when going quickly from closed to open.
- Instantly choke all voices when a pedal articulation is triggered.
I was hoping the complex group functionality would do a good chunk of this. But I suppose it is the wrong tool?
