lokey=next and hikey=next

[MTornPDX]

I've just learned about the pitch_keycenter=sample, which is great, especially since you can put it in or . Using this you can just drop in properly tagged samples without having to type in all the root notes. However, for proper keyboard mapping you still need to code in the lower and upper limits of the key span. Most regular samples allow you to automap, spreading the key ranges to fill all the blanks between the root notes.
A pair of opcodes could do the same in SFZ.
lokey=next would extend the lokey automatically to where the next region begins (or to the bottom of the keyboard, if no lower region exists). Similar, of course, with hikey=next. If hikey=next is used on a region, and the next region up uses a lokey=next, the border between the two regions would split the difference and meet halfway.
This would allow you to easily drop samples in and out of the SFZ file, and the mapping would respond quickly and dynamically. All you'd need to do is to put lokey=next and hikey=next in the or .

[jpcima]

It would possibly work for simple instruments, but this will not work as soon as it has to deal with layered voices with overlapped key ranges, or those whose activation varies conditionally.

While it's true that sfz is verbose in order to accomplish functionality sometimes, perhaps this is best dealt with external tools.
The various automapper scripts are an example of that, but I'm sure one could go into much deeper functionality by use of more elaborate text generators (eg jinja2).

[MTornPDX]

Perhaps, but in the cases where you need unusually complex mapping, the normal way is still available. In general, it's rare (and poor practice) to have overlapping regions without putting them into multiple groups, wouldn't you say? And within each of those groups there might be cases when =next could be used.

In the cases of conditional activation, that would behave just as if you had typed in regular hikeys and lokeys. The hikey=next wouldn't react to changing conditions, it would only assign automated hikey and lokey values upon loading the patch.

Relying on external tools is troublesome, I think. They are often only available for a single platform, and are often quirky, inaccessible, and unreliable. I'm using the apps by Bjoern Bojahr, and they are great, but they were written in 2004, and it's nothing short of a miracle that I can still use them on my Mac. I wouldn't trust that they will be available for long.

Occasionally Bjoerns Sample Mapper will get the root note for a region wrong. In those cases I have to figure out not only which note it is, what root note and key range it SHOULD have, but also the same thing for all the adjoining notes. And Bjoerns Sample Mapper doesn't list the region ordered by root note, it does it alphabetically, which means that the offending regions can be nearly anywhere in the list.
If =next was available, all that needed to be done is to assign the correct root note to the offending region, and it's done.

[AlexMitchellMus]

Considering the heterogeneous landscape of SFZ instruments, there are very little enforceable rules, appart from basic grammar.

Without some sort of way to lock a group of samples into a logical unit, I don't see an easy way to accomplish this.

I mean, maybe it would make more sense for an opcode that could be placed in region (or group level) that would let the player know that the provided samples are to be auto mapped?

auto_key=<id>

That way there can be more than one automatic key mapping?

But it does feel very problematic. Most instruments are not single samples, having round robins, and multiple velocity layers.

Any such mapping would have to take that into account, and deal with any issues that arise.

This is the job of either a dedicated SFZ instrument editor, or possibly a meta-language that could assemble SFZ scripts.

AFAIK Kontakt does both, it's offline scripting is done in Lua, where a library maker can write a Lua script to assemble an instrument.

[MTornPDX]

alcomposer, could you describe what you mean with auto_key=?
I'm not sure I follow what that would do.

Keep in mind that any "extend zone to next region", of it's viable and people want it, should have the option to only extend regions down, up, or meet halfway. Christian Henson of Spitfire and Pianobook thinks that we should only pitch samples down, never up. Not sure if I fully agree, but the wish is there.

Also, can you or jpcima describe a specific scenario (or maybe paste in some SFZ code) where something like hikey=next would be troublesome? I'm not saying it's always the best way to go (compared to the current way), but I've tried to think it through, and can't think of anything to rule it out.

[AlexMitchellMus]

The only way I can see this working is if there was a complete auto mapping opcode.

Point it to a folder of samples, and set mode/s of operation.

That way round robins can be built, and velocity layers.

However this starts to feel quickly like the place of an editor. For example once all the auto mapping is finished where do you introspect the generated regions?

You would only be able to play the instrument, not see what was generated by the automapper.

[MTornPDX]

I ran a few mockups, to see if hikey=next would pose any real conflicts. For moderately basic layouts I'm still a fan, but it's when you start getting complex, with round robins that has varying key spans within a group (rare, but possible) that things fall apart a little. Same with hivel and lovel, and hiand and lorand - but they are only a problem if you were to assign them asymmetrical (ie different for hard and soft velocities) key spans within one group.

The fact that you couldn't see the exact key span that was created for each region isn't a huge problem, the same way as you currently can't see the root note assigned to a region with pitch_keycenter=sample. (although, in fairness, that might cause confusion too)

Maybe your thought to have an auto mapped opcode might be viable? Instead of having the point to a sample file, have it point to a whole folder, with something like map_key_centered, map_key_down, map_key_up. You could still assign things like a key span, velocity span, etc, which then would apply to the whole mapped folder as a unit. I like it!

[AlexMitchellMus]

We have to think what is the problem that such feature is trying to solve. And in so doing, what is the workflow of that solution.

If one has a folder of samples that are already processed and contain metadata, how did it get there in the first place?

Given the huge job of editing recording down to samples, injecting metadata etc, it feels like an auto-mapper isnt the greatest problem right now.

Apart from a simple auto tuning opcode (through audio analysis) it's really hard to see a complete automapper work 100%.

The effort would be better spent on a SFZ Development Environment. One that would allow the user to tag multiple samples, place them on keys, setup the instrument, and export to SFZ format.

Samplerobot is a good example of such a tool. Something similar would be really useful for SFZ.

[MTornPDX]

I think the primary problem I think a dynamic auto-map opcode solution would aim to solve is to allow people to build a substantial SFZ library as quickly as possible, with a little tedium as possible. Building a library could refer both to ones personal collection, as well as a global resource.

A secondary benefit is that it would allow for an easier way to allow for some more spontaneity and experimentation with the mapping, allowing you to try things out, and to switch things out on a whim, without being slowed down too much by hand coding.

Building a new SZF patch typically starts with a folder of sample files, right?
Speaking for myself, either I produced them myself (like multisampling an instrument), or it something I found elsewhere that I'd like to import to SFZ (I'm doing the huge collection of instruments that come with Logic Pro right now, but it could also be something I've downloaded, from a place like Piano Book). The sample names will ALMOST always have the root key at the end, either by note name (Flute C3.wav) or number (Flute 60.wav). This is all we need.
I also like to have the root key embedded in the sample metadata (I use Bjoern's Endless WAV app for this, it can do it as a batch, by reading the file name), because some samplers can read metadata but can't parse the sample name. But if any kind of auto mapping were to be added to the SFZ protocol, it would make sense to allow it to use the root key in the sample name, and not require it in the metadata.

Personally I feel that having some degree of discipline and organization of how your files are named before building your SFZ is just good housekeeping. In the cases where you don't want to bother with any kind of naming system, or if a system just doesn't make sense for the sample material, then all that means is that those samples aren't a suitable candidate for auto mapping.
No audio analysis should be needed, but if you have a sample editor that can do it, it can of course be used.

One problem with something like Samplerobot or Bjoerns Sample Mapper is that they will produce an SFZ starting point, but if there is any desire to tinker with mapping after that initial step, you have to either hand code those changes, or start again from scratch.
Another problem is that it requires you to find and maintain (and pay for, in some cases) more software. The fact that you already need two pieces of software to make SFZ files (the plugin and the text editor) is probably enough of a turnoff for some.

I dream of a full-featured sampler plugin that uses the SFZ standard for its files, but is otherwise a typical classic graphically driven plugin. A replacement for Kontakt or Logic Sampler, if you will. With a terminal window for the extra clever things that are best coded by hand. Seems possible, but a massive, probably commercial, undertaking.

[SpotlightKid]

I think auto-mapping of samples should not be part of the sample playing engine. Too many variables, often depending on personal preferences (e.g. file naming). Tools that could read an existing SFZ and alter the sample mapping according to some given parameters (e.g. maximum stretch, whether to prefer samples higher or lower than the target key, etc.) would be helpful, though.