The Sample Map of The Future: Escaping the 20th Century Sample Mapping Paradigm

Christoph Hart

@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.

Simon

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.

Christoph Hart

@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.

Simon

@Christoph-Hart For automatic gain matching, I'll gladly put all my legatos in the same sampler :)

Simon

@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.

d.healey

@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

Simon

@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.

Christoph Hart

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.

d.healey

@Christoph-Hart I leave them as linear fades and rely on CC smoothing for the curvyness.

Simon

@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.

d.healey

This post is deleted!

Simon

@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.

d.healey

@Simon Now you mention it I sometimes do that dipping technique as well.

Christoph Hart

@d-healey alrighty, then I'll make two separate logic types for the fade (one called TableFade with the tables and one called XFade using the inbuilt fade types). I'll probably exclude the table fade for the MVP , as it's a lot of boilerplate and some UX annoyances to get there.

Ideally you can then use multiple dimensions of fading layers, so you if you have a matrix of 3 dynamic layers and vib / no vib, you can then fade between all 6 samples using two different CCs.

griffinboy

@Christoph-Hart

Lovely work, puts my sampler to shame

griffinboy

bitmask

Thanks for introducing me to bitmasking. Oh my goodness, I can't believe I didn't know about this before. So useful.

Christoph Hart

Alright guys, closing in on the MVP for this new system but this begs a few questions: there are a lot of half-baked / duct tape solutions for group management in the sampler which I would like to deprecate:

cached round robin group collector. This is an internal optimization that can be enabled with Sampler.setSortByRRGroup(). The new system includes that optimization but is definable per layer / tag so I would love to remove that as a global option. If you're relying on this function you can just enable the new complex group system, use a single RR layer and activate the caching there. If there's a lot of people using that I can think of a migration tool otherwise I would just deprecate the function call and make it throw an error message when you try to call it from your script
multi RR group: previously this was the "recommended" way to handle both XFade and RR groups within one sampler, but it's buggy, annoying and never really worked well, so I would suggest to remove it altogether. The new system 100% replaces this functionality with a better UX and more flexibility. This would affect all calls to Sampler.setMultiGroupIndex() / Sampler.setMultiGroupIndexForEventId(), which will be replaced by the generic Sampler.setLayerFilter() that you just need to pass the index of the RR group.
RR group volume: not sure who requested that (David?), but this could also be handled more gracefully by the new system by defining a mixing layer that you can directly access and set its volume. This would affect the call setRRGroupVolume() so if you're using that you'll have to redesign it a bit (please let me know the exact use case there so I can cater in that functionality into the new system).

I would heavily suggest that I make everyone of the mentioned API calls throw at the compilation so you need to port the scripts over to the new API. If there is a 100% equivalent under the hood I can try to maintain the old call, but otherwise it will just be dead weight going forward.

Christoph Hart

@Christoph-Hart forgot a few:

Sampler.getRRGroupsForMessage() - this is also deprecated, if you have a samplemap with varying amounts of round robins, you can define multiple RR layers with a separate cycle length each.
Sampler.enableRoundRobin() / Sampler.setActiveGroup() now that's a tough one as these are probably the most used one, so I probably will not throw an error but just print out a passive aggressive console message that will nudge you towards the new system, but you can now just either create a "RR" layer that will use the default cycle behaviour, or a "Custom" layer that does nothing by default and can be used for custom scripts.