Loop part of a sample

[BBGuy]

If possible this will allow having sounds with an attack sustain and decay.

Pressing and holding a key will: play the sample from the beginning until the end of the loop part and then jump to the beginning of the loop point that can be set after the attack.

Once the key is released: The sample will play from its current position to the end and if the endpoint was set before the start of the decay

Sample:

     ---
  /      \
/         \

(---) Looping part of the sample

[marchingband]

Ok lets keep the looping discussion over here, in #2 @solipsvs said

please allow start index, loop index, loop end index, and end index per sample. this will allow many amazing sound possibilities. it would be great if you could feed WVR files with these loop points defined and saved in the header.

then of course all the loop types like forward, backward, alternating.

if you really want to go the distance, to allow the sample start, loop start and loop end points to be controlled with cc... that allows some wizardry and i would buy beers for you.

[marchingband]

From a UI perspective, how would this be best achieved? We have the waveform view to show the points graphically. Setting the points COULD be done with clicks on the waveform view, although it would be very hard to code, and a little inaccurate, and potentially annoying to try to get them perfect when clicking on a little waveform on the screen. The easier way from a code perspective, and perhaps the best for accuracy and UX, would be some text boxes, where the user could enter sample indexes for each point. I could add an option to the mode drop-down menu, maybe called ADSR to activate these boxes. I think we only need 4 numbers, and they could have defaults like this: start -> 0 loop-start -> 0 loop-end -> 12,345 (or however long the sample is) end -> 12,345 (or however long the sample is)

I think these could be tweaked to get all the results needed. Some vertical lines on the waveform view could visually show the points as they are modified by the user.

In terms of CC control over these points, it could certainly be done, but, it seems more like a custom firmware feature, then something everyone would want. I am open to being wrong about that though, if people feel differently.

[marchingband]

Note that this will be a pretty major chunk of dev time, as it requires some big changes to the audio engine, so it may not happen soon, but I agree it would be amazing, so I will definitely start working on it when I have some time.

[solipsvs]

ok so one of the things i find very nice is being able to choose a start point for my sample using a cc value, this way i dont need to make any slices, i just need to send the start point before i trigger the sample. then my loop point can remain 0 and wherever i start the sample from it will loop back to the beginning. this is extremely useful for drum loop manipulation.

another use is wave scanning, which could tie into wavetable playback mode in the future. wavetables are amazing and offer more realism and easy synthesis options. i gather a wavetable oscillator is not the same as a standard wave playback.

[marchingband]

@solipsvs you COULD achieve this, without making slices in your DAW, by selecting the same wav file into multiple notes, and then use these proposed ADSR points to select different slices on different notes. Then you wouldn't have to send the CC, you could just send the appropriate midi note for the slice you want ... either way I would be excited to work on the CC solution with you as well, I am just not sure that it's universal enough of a need to put it in the default WVR firmware. I think a wavetable mode is a really good option, lets continue that discussion over at #22

[solipsvs]

in the old school tracker interface was included a way to address your loaded samples directly and with a sample start index 0 to 126 or some other commonly used number system. this would allow you to slice the audio exactly half way or 3/4 or whatever the resolution allowed for, for every note. for every sample. so you could apply this to anything loaded in the sample pool. of course, it only really makes sense if your samples are formatted to the process of subdivision, like drum beats. it also enabled some rudimentary effects like echoey time stretch etc. so a way to access those points in a sample easily is definitely conducive to creative use.

[solipsvs]

From a UI perspective, how would this be best achieved?

how about markers and some sort of boundary that changes colors? i need to actually see the interface before i make a comment lol (dont have my WVR yet)

[BBGuy]

@marchingband I think that your ADSR proposal is going to be great. I also think that the underlining functionality is the important part and not the UX. It's easier to use a tool like Audacity to work your points out. I would add the ability to use the file name to specify those. something like kick_start0_lstart_lstart50_lend500_end1000. I like the ideas @solipsvs is proposing but agree they are more niche. However if while coding you get the opportunity to make those points as targets that would be cool.

I wonder if we should not come up with a format to name files in a way that allows for various parameters. will start a new issue for that

[marchingband]

@BBGuy With this ADSR feature, does the playback jump immediately to the release index, when a note-off event occurs? Or would it be acceptable for a note-off to simply stop the looping. For example, if a note-off happens while playback is mid-way through the looped section, can the playback continue from where it is, finish the looped section, and then proceed past the loop point, and play the release? Or does it need to skip the remainder of the looped section, and immediately play the release section? I am assuming the latter is the expected behaviour, but just want to confirm.

[solipsvs]

i would prefer that a sample given a note off while in the loop portion finish the loop portion and then move to the end portion while fading. if the fade is short enough to happen before it gets to the end portion, then dont play the end. jumping from the middle of the loop portion to the beginning of the end portion would potentially make a pop.

[BBGuy]

Yes just stop looping and play from the current position to the end.

[solipsvs]

hey hows the holidays? any new progress? github is pretty quiet cheers! On Monday, November 22, 2021, 04:49:28 AM EST, Guy Schneerson @.***> wrote:

Yes just stop looping and play from the current position to the end.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[marchingband]

@solipsvs holidays ha! not for me. I am working around the clock on the last reward, the Thames pedal. Lots of challenges coming up with handling massive sample libraries. Good to know everyone seems to agree that just continuing playback, and not jumping to the release, is the way to go. I would have thought that jumping to the release was important, which would have made it hard or impossible in the current audio engine implementation.

[solipsvs]

jumping would create a pop potentially.  you need dsp to fade tho, correct? continuing to release could add to the perceived sustain period unless you fade out good to know the silence doesnt mean inactivity.  wish i could help.  i realize i dont even have a perspective on what coding really takes, like what volume of code is created for each little feature request etc.  i think refinements will eventually serve the end users experience and therefore the quality of the product.  musicians appreciate attention to detail. i know i do. On Friday, December 10, 2021, 02:01:35 PM EST, marchingband @.***> wrote:

@solipsvs holidays ha! not for me. I am working around the clock on the last reward, the Thames pedal. Lots of challenges coming up with handling massive sample libraries. Good to know everyone seems to agree that just continuing playback, and not jumping to the release, is the way to go. I would have thought that jumping to the release was important, which would have made it hard or impossible in the current audio engine implementation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.