The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm
-
@Christoph-Hart In your example samples get assigned both an RR and a group XFade, were you planning to add separate controls to manage and filter group xfades?
-
@Christoph-Hart said in The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm:
or would assigning a sample a note and rr value still put it in the mapping editor?
Yup, Samples are still mapped in a 3+ dimensional space. Currently it's X = note, Y = Velocity, Z = RRGroup. With the new system it's X = Note, Y = Velocity, Z = BITMASK!!! and this bitmask can handle multiple dimensions of organisation (keyswitches, articulation types, RR, whatever you need).
The library I'm working on would not have been possible without HISE's "Enable MIDI selection", which let me adjust volume, pitch, start, and end of my legato samples to match them to the sustains.
This should still be possible, it just selects what is played back most recently. If you have now multiple types in one sampler (eg. sustains and legatos), it might be a little bit tricky, but we could then also apply the bitmask filter on what to display
Ok well Im pretty much in - where do I sign?
Just for my clarity tho - we now "map" samples into the 3d space by using the 2D (velocity x note) space in the editor - and we use the name of the wav file to assign it in the n-dimension Bitmask - so some set of tokens like:
InstrumentName_Velocity_NoteNum_MicPosition_RRGroup_XFadeGroup.wav
Where our bitmasking system ignores the velocity, note num, and mic position tokens..because we've defined a set(array) of strings that define what will appear for each position in our bitmask, e.g.round robins:
const var RR_GROUPS = ["RR1", "RR2", "RR3", "RR4", "RR5", "RR6", "RR7"];
xfades:
const var XF_GROUPS = ["XF1", "XF2", "XF3", "XF4" ];
Is this right?
In fact wouldnt it be much nicer if we were not declaring these token arrays every time we loaded a new sample map - and we moved them into the samplemap xml itself?
or is that waht this thing is for?
ID: "XF", LogicType: "Crossfade", IndexInFileTokens: 2, NumMaxGroups: 4,HISE Development for hire.
www.channelrobot.com -
@Christoph-Hart said in The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm:
Everything that isn't masked out will be played, yes - in my example above, all the XFade layers pass the bit mask test and are flagged for playing.
Can we filter it further, play a note, then filter again within the same callback? The idea in the original post is to make use of the eventData concept to allow per-sample modulation.
Or is the thing that we now use the good old note x vel 2d map to choose the individual samples?
-
Is this right?
Yes.
Can we filter it further, play a note, then filter again within the same callback?
You can always apply your own filters to filter out a layer. I'm currently writing the data container, it will all clear up soon.
-
@Christoph-Hart said in The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm:
Is this right?
Yes.
In fact wouldnt it be much nicer if we were not declaring these token arrays every time we loaded a new sample map - and we moved them into the samplemap xml itself?
HISE Development for hire.
www.channelrobot.com -
@Lindon said in The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm:
In fact wouldnt it be much nicer if we were not declaring these token arrays every time we loaded a new sample map - and we moved them into the samplemap xml itself?
sure, if the layout changes between samplemaps then this shouldn't be an issue.
-
@Christoph-Hart Im trying to work out in my head(and lets be frank theres not much room left in there)... how I might use this to manage True Legato - so thats start note fades to transitioning sound fades to target note.
If it doesnt obviously support this in a simple way maybe we can think about how a 21st century sampler would manage that......
HISE Development for hire.
www.channelrobot.com -
@Lindon I‘m working on exact that use case right now. I just need to work out a way how to make it efficient in the backend.
-
I don't see this particularly affecting legato. I would still put sustains in one sampler and legato samples in another, which makes it easier to adjust envelopes and manage the sample maps.
The biggest change for me here is being able to use dynamic xfades and round robins simultaneously in one sampler.
-
@Simon having legatos in the same sampler does bring some benefits (eg. Automatic gain matching like with the release start and zero cross aligning the start for less phasing during the fade).
In the end it‘s just another filter with 128 options - the legato sample will be mapped to the target note and this filter is set to the source note.
-
@Christoph-Hart For automatic gain matching, I'll gladly put all my legatos in the same sampler :)
-
@Christoph-Hart You've probably thought of this already, but just in case:
Ideally the legatos would be matched to the sustains, not the other way around. The start of the legato sample should be matched to the end of the source sustain, and the end of the legato sample should be matched to the start of the target sustain.
An envelope seems simplest to me, or a compressor/expander. In any case:
- Apply a gain offset to the legato sample, to match it to the source sustain
- Apply an envelope to the legato sample, to match the end of the legato sample to the target sustain
The envelope attack time and curve might be worth exposing as options, or maybe a fixed curve is enough.
I have spent a lot of time working on legatos and have equally many opinions on them, so I am very excited to see what you are working on.
-
@Simon said in The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm:
The biggest change for me here is being able to use dynamic xfades and round robins simultaneously in one sampler.
Already possible, see Lindon's recent thread
-
@d-healey I know you technically CAN, but I mean in a way that is easy to work with, and doesn't require using RR groups for two different purposes.
-
Quick survey: how much of you that are using the Crossfade feature actually use the tables for customizing the crossfade curves? I mean changing this
to something like this:
The reason I ask is that now we have that nice xfader node available in scriptnode, we can just use its algorithms to replace the table curves which makes it much faster to calculate and easier to implement / maintain (I'll include a few fade types which should cover most use cases):
I'll keep the tables around in the old system for backwards compatibility of course, but not having to drag this tech debt to the new system would be nice.
-
@Christoph-Hart I leave them as linear fades and rely on CC smoothing for the curvyness.
-
@Christoph-Hart Me, 100% of the time. I adjust it until the xfade feels right. I also pretty much never want a linear fade from one to the other, but expand the dynamic range by making the lower dynamic fade down in the lower range.
-
This post is deleted! -
@Christoph-Hart I would not at all be opposed to having the common curves as presets, but it's quite important to be able to adjust the curves for feel.
-
@Simon Now you mention it I sometimes do that dipping technique as well.
