Waveform Bar?
Hi
Is it possible to add a moving position bar to a waveform object so that when a sample is running freely, you can see which section is playing at a glance?
Many thanks as always.
p.
Use snapshot from the sync outlet of groove.
Scale the 0.-1. to the length of the waveform, and plug this into a line $1 message box which is connected to the leftmost inelt of waveform.
I’m not 100% sure I’m following you here…
So, the sync outlet from groove~ plugs into the internal clock interval input of snapshot~?
Then snapshop~ to line $1 to leftmost waveform inlet?
Sorry, really bad explanation from me!
Here’s an example, you could also do this without waveform, just plug the outlet of snapshot~ into the left inlet of a multislider with a range of 0. to 1.
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.
Thanks again for your patience and help.
The problem was that when the selection was changed, the range of numbers sent to the line $1 message was still the entire length of the buffer. It needs to be scaled to the length of the selection.
Here are 2 ways (sort of) of sorting this:
Superb, thanks!
Great stuff!
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, that’s real purty 
Clever too.
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.
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.
pmj wrote on Mon, 22 June 2009 10:56
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.
Enjoy!
save as waveform_zoom.maxpat
example patch:
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
Thanks
p.
Ok, so the question now seems to be how do I pass the newly selected sample length info from waveform~ through to the scrub sampler.
At the moment, I can take it from the info~ object, but this reads the full length of the sample in the test buffer.
I should be able to take the new length info from the numerical output from the waveform~ object somehow?
Key objects as I see them are marked in purple (below)
Any suggestions gratefully recevied.
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.
Thanks… yes, have abandoned that sah~ idea as a red herring.
Back to the drawing board with the clicks.
OK, sorry to bring this up again but I’m finding no solution to the new loop point selection clicks. It’s a shame as it ruins what is otherwise shaping up to be a very interesting patch…
If anyone has found an answer to this, I’d be very grateful for a pointer here as I seem to have hit a dead end.
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.
_
johan