Very helpful, that makes a bit more sense... thanks very much!
Only one thing is now if I highlight a specific section of a file to make my loop on the fly, the position bar continues to travel the full length of the waveform, not just within the bit I've selected.
Possibly I wasn't asking the right question to begin with here, but any idea? Have reposted the original patch with your example incorporated into it.
It was fun to mess around with, so I added some extra goodies and rearranged things, take a look if you're interested. Also the waveform tool selector didn't work for me, the [coll] buried inside had lost its listing, so I just made buttons to set the mode instead.
Wow, thanks for this, guys. I've been wanting to add the scrolling line + select/zoom functionality to one of my performance patches for awhile. I think I should be able to use these examples to do that, now.
Now if I can only get around the clicking that happens when you set a new loop point in the waveform window, we'll have a winner.
grooveduck~ tidies up the looping once you'ce selected your points but not the initial thump you get making a new selection.
a couple things to try are the mouse mode, which can be set to only activate upon release, or other combinations. In the example it's set to "continuous" which will constantly update the selection range as you move, and that'll cause clicks. I think grooveduck~ also smooths out the loop selection by using quick ramps at the beginning and end, which you can implement with trapezoid~.
You could also send the selection points into [f ] and hold them until the loop finishes, then bang them out to choose the new loop points. the advantage is that the full prior loop plays out before the new one, like it does in Live and other apps. To tell when the loop ends you can use [delta~] --> [edge~] --> [>~ 0.] on the right outlet of groove, like in the patch below, which will tell you right when it jumps from the end back to the beginning.
this version uses [f ] to hold the loop points, plus implements a simple grid for the waveform~ which you can set with a bpm and then use a multiplier. So if you have a steady, beat-based audio file where you know the bpm, try setting the bpm in the patch and jumping around the file, the loop points should match pretty well with the audio's beat timings.
you can also do some really fun stuff with [mtr] and the selection beginning/end points... give it a try
Just been messing with the zoom idea and making a UI that can be loaded into a bpatcher.
If you have not used them before, they are like sub-patches, but showing in presentation mode. Save the waveform_zoom.maxpat in your main patch folder so its in the search patch, then open my example patch to check it out.
I suggest trying to include seejayjames' suggestion of using f to store the new loop points until the loop finishes ala Live. It seems like a useful feature to be able to switch in and out.
This is all fantastic stuff guys, thanks s much for all the help and suggestions.
Just one thing regarding the initial click when selecting a new loop point in the waveform, if you put a [sah~ 0.01] between the selection start output from waveform and the loop min input of grooveduck~, it seems to minimise the clicks somewhat and also force the selection to finish before playing the next loop selection ala Live etc.
OK, while we're expanding the ideas on this, where would be a sensible place to incorporate the Scrub Sampler from the Max examples folder into the patch?
I've tried taking the output ramp from [zigzag~] into the sample increment input in [grooveduck~] and it seems to overload everything with whitenoise and weird high frequency modulating noises... quite nice in it's own way, but not what I was after
Loop length = selection end - selection start. Use outlets 3 and 4 from waveform~, and experiment with the - and !- objects. See which one works for you. Keep in mind that the leftmost inlet of - will trigger the calculation.
EDIT - the reason you aren't getting clicks when selecting is that sah~ is constantly outputting a signal of 0. The selection start is never changing, so you need to find another way around the clicks if you want to be able to select properly.
Long ago I suggested the feature for the groove~ object to evaluate a new selection upon reaching the end of the current selection (after some behavior that I was used to with Kyma). It has never been implemented, as far as I know. If you make the request once more, maybe this time it does not meet deaf ears.