[RFC] Auto-sampling.

[take0ut]

Deluge is the best hardware multi-sampler I've used, and I'm constantly wishing it had the ability to create multisamples from connected midi instruments.

This is possible manually, without too much difficulty—resample a midi clip with your synth coming in on a monitored input—but is cumbersome and difficult to organize. We could handle it automatically for users.

While I'm not fully familiar enough yet with the Deluge codebase, the general idea would be to have a multisample control available from the community submenu. Engaging the autosample option would present you with a list of options (pressing the select encoder would navigate to the next option, similar to how LFO modulation is handled on clip parameters).

Note

MIDI Channel (1-16)
Audio Input (L/R/ST)
Low note (default to C0)
High note (default to C6)
Note interval (default to octave)
Note length (default 5 seconds) — could use threshold detection to find the end of a sample
Note velocity (default to 100)
Synth name (saves to SYNTHS/AUTO/)
OK?

When the user selects OK, the sampling process begins.

Synth preset saved to SYNTHS/AUTO/.xml
Samples saved to SAMPLES/AUTO//.wav

[PaulFreund]

Since this function would not change user facing behavior (only introducing a new menu option) I think you don't need a community setting for it and you can put it directly in the main menu.

Regarding the options maybe have a lowest and highest note and a jump offset? (at least for me that is the easiest to understand). In addition to length velocity might be required.

Would really love the Deluge being able to do that!

[take0ut]

Thanks for the comment! I felt like all the "new" options should be sequestered under the community menu—but not hard to edit.

[opyate]

velocity might be required

The 1010music nanobox tangerine calls this "velocity layers", I think (source). It would be very useful.

PS BoBeats also remarks that he accidentally sampled panning automation too, which is probably not what you want, so perhaps the Deluge can warn if some possibly-unwanted modulation is active before you start.

[weavermedia]

I'd love to see auto sampling on the Deluge. I do a lot of auto sampling with Logic AutoSampler (previously in Main Stage) which has a good balance of ease of use and features.

I agree with @PaulFreund, the user should choose Low Note and High Note and Interval. Also agree with velocity too since you might want to take multiple versions of the same synth sound at different velocities.

Not sure what the Sample Root setting is for since each sample will have it's own root note and the span set to the interval range.

The sampling process would need to capture the decay portion of the sound after the note has ended. Meaning even if the Note Length was set to 5 seconds the sample might end up being 8 seconds if the sound has a long decay. This would presumably be done with some kind of threshold detection.

So the modified list would be something like:

1. MIDI Channel (1-16)
2. Audio Input (L/R/ST)
3. Low note (default to C0)
4. High note (default to C6)
5. Note interval (default to octave)
6. Note length (default 5 seconds)
7. Note velocity (default to 100)
8. Synth name (saves to SYNTHS/AUTO/<name>)
9. OK?

For the saved files how about:

• Synth preset saved to SYNTHS/AUTO/<name>.xml
• Samples saved to SAMPLES/AUTO/<name>/<note>.wav

[take0ut]

Sample root was basically supposed to be "lowest note". This articulation of the parameters makes much more sense, thanks!

[jamiefaye]

Auto sampling sounds like a terrific Wren project. Of course we don't want to make everyone who wants to auto-sample learn scripting. So this means Wren should be able to prompt for the parameters required and then coordinate the process.

[take0ut]

I assume we're still pretty far from Wren working as an interface to the audio recording functionality?

[jamiefaye]

Wren has some issues that need to be addressed. Wren consumes a fair bit of memory and we do have to figure-out how to expose the Deluge internals in a sustainable way. If it were me, I would tackle this issue through a web-based interface and a SysEx tunnel. SysEx tunneling has some of the same issues as Wren in that we are defining an API we don't want to change very often. So I am fine with something that uses the built-in display for now.

[take0ut]

Thanks for the comments, all! I'm eager to start working on this. Currently waiting for my Deluge to return from NZ, but have been attempting to sketch out the code. I haven't touched C++ since college, so it's a bit like riding a bicycle with fifteen wheels.

Main takeaway I have so far is that we should implement some kind of threshold detection utility for audio inputs. Do we know if anything like that is currently in the codebase?

Additionally, does anyone have prior knowledge of how buffer recording works on the Deluge who could be a rubber duck as I work on this (or, obviously, an IC on this feature. more than happy to collaborate with anyone).

PS: Housekeeping question, for @jamiefaye —should I continually update/edit the first RFC post with changes as comments come in, or should I let the discussion build in the comments. First open source project for me!

[jamiefaye]

Please update the RFC so people don't have to read all the comments and figure out which ones add up to "truth".

[weavermedia]

If there was existing audio threshold detection code I imagine it would already be used in the sampling process. Threshold triggering is a long-standing feature request. There's a mention of audio threshold detection in sample.cpp (find "Rudimentary audio start-detection") but it's in the pitch detection function. Might be something to base it on though.