MF_Voltron

im working on a patch that uses lists sent to line~ to control play~, using a matrixctrl to select which parts or 'clips' of the sample playback in which order. ie coordinates 1 1 1 would play the first clip from the first position, forwards. 2 2 1 would play the 2nd clip from the 2nd pos. forwards and 4 1 2 would play the 1st clip from the fourth pos. , backwards. 

so a tempo object reads thru the matrixctl horizontal values, the vertical values represent the same as the horizontal so that the play order can be changed up, and the value of the cell (0, 1, 2) shows whether it plays a sample and whether it is forwards (1) or backwards (2). All this data is compiled into a list using pack and changeable arguments in message boxes, and is sent to line~ every tick. At this point play~ produces the most horrible mess of samples at different speeds which doesnt make sense as the ramp time sent to line~ is always the same and the gap between start and end points sent to line~ should also be the same everytime. 0, 500 in 500 ms should always be the same but i have had this problem when re opening a patch that 0, 500 in 500 ms will be played back 2x or half speed!

I think that part of the problem is line~ being sent too many numbers in quick succesion so some of the lists are interrupting eachother (?) and the line sent to play is constantly changing.

the kind of lists sent (in 120 bpm) are 0, 500 500 ; 250, 750 500 ; 500, 1000 500

any ideas? il try and upload the patch soon

im working on a patch that uses lists sent to line~ to control play~, using a matrixctrl to select which parts or 'clips' of the sample playback in which order. ie coordinates 1 1 1 would play the first clip from the first position, forwards. 2 2 1 would play the 2nd clip from the 2nd pos. forwards and 4 1 2 would play the 1st clip from the fourth pos. , backwards. 
so a tempo object reads thru the matrixctl horizontal values, the vertical values represent the same as the horizontal so that the play order can be changed up, and the value of the cell (0, 1, 2) shows whether it plays a sample and whether it is forwards (1) or backwards (2). All this data is compiled into a list using pack and changeable arguments in message boxes, and is sent to line~ every tick. At this point play~ produces the most horrible mess of samples at different speeds which doesnt make sense as the ramp time sent to line~ is always the same and the gap between start and end points sent to line~ should also be the same everytime. 0, 500 in 500 ms should always be the same but i have had this problem when re opening a patch that 0, 500 in 500 ms will be played back 2x or half speed!
I think that part of the problem is line~ being sent too many numbers in quick succesion so some of the lists are interrupting eachother (?) and the line sent to play is constantly changing.

any ideas? il try and upload the patch soon


trouble-controlling-play-with-lists-to-line

would this all be a lot easier and better if i just used groove~ and scrapped the whole line~/play~ thing? i was using play~ because of its emphasis on playback from different starting positions but it all seems like it would be easier to rebuild my patch with groove~ now!

Hi, your patch sounds a bit complex to understand it all in words, if you uploaded it, then it might be easier. Particularly, because I can understand the play~ and line~ but many people have different ways of using matrixctrl to sequence and it sounds like yours has some specific time-reformatting math that i'm not really able to picture in my mind as easily. So just going by what you say, i think you're right and line~ is probably being sent too many messages at once which would cause line~ to interrupt it's trajectory with the instructions of an ever-changing message. Instead, when you are doing something like this in particular, you want to look into using poly~. Poly~ will ensure that a voice will play all the way through before it is free to accept another playback message(i.e. the message sent to line~ controlling play~). In the meantime, while a voice is busy, a new voice or set of voices will be playing all the other messages being sent individually. Take a look at the tutorials on using poly~, it will help you alot. As for groove~, yes, you can do this with groove~. But you might still want to put groove~ in a poly~ to ensure that messages plays through uninterrupted. Using groove~ is not necessarily better, just perhaps easier depending on your needs.

If however, you DO want to be able to interrupt a message to line~ then you will have to be clever about the messaging: sending and then 2.5 seconds in, sending is actually the equivalent of sending something like this: (in other words, start at 0, go to 0.5 in 2.5 seconds, then go straight to 0 in 0ms and then up to 1.0 in 5 seconds). Instead look into using line with two-element lists(sending will set the ramp to 0 in 10ms then you can start the true playback ramp from there (or whatever) and this ensures you actually have the ramp what you wanted everytime so long as you ALSO create an amp-envelope that would cut out the noise of any extraneous ramp resetting.

Anyways, hope that's not too convoluted, but I just meant there are many things you could try: basically either taking care of each individual message to line~ within a voice of a poly~ or making sure line~ only does what you want it to do when you want it to by explicitly setting and resetting it. Best of luck!

If however, you DO want to be able to interrupt a message to line~ then you will have to be clever about the messaging: sending  and then 2.5 seconds in, sending  is actually the equivalent of sending something like this:  (in other words, start at 0, go to 0.5 in 2.5 seconds, then go straight to 0 in 0ms and then up to 1.0 in 5 seconds). Instead look into using line with two-element lists(sending  will set the ramp to 0 in 10ms then you can start the true playback ramp from there  (or whatever) and this ensures you actually have the ramp what you wanted everytime so long as you ALSO create an amp-envelope that would cut out the noise of any extraneous ramp resetting.

Anyways, hope that's not too convoluted, but I just meant there are many things you could try: basically either taking care of each individual message to line~ within a voice of a poly~ or making sure line~ only does what you want it to do when you want it to by explicitly setting and resetting it. Best of luck!


cheers i will look in to using poly~ and also probably rebuild the patch with groove~ if it still doesnt work after this i expect il upload it... pretty annoying as i spent whole days working out how to convert values from matrixctrl into the right kind of list for line~ hheehe

oh hey! if you use poly~ you don't really need to change those messages to line~. just in case i'm being too confusing, here's something i used with the same exact line~/play~ setup it sounds like you have but there's other stuff which might make it hard to poke through(minimum/maximum to make sure starting-loop point is always before ending-loop point, granular-style amp-window, and this 'auto-scroll' function which allows for time-stretching and some extra stuff to switch playback between two buffers).

I've attached as a zip here cuz there's two files, one is the poly~ patch called samplecutvoice~(the guts of the playback functions) and the other is called samplecutvoiceDev which is the one you open to test it all out. Hope it's less confusing than my words.

oh, and one last thing, the sampcutvoiceDev patch sometimes requires restarting the audio couple times to get the audio running, not sure why, but once it's running it stays running fine(you should see bangs coming from the edge~ below the phasor~ when audio is on, if not, stop and restart audio). not sure why this happens but if you thin it out for your own purposes and still have the same problem, we can probably figure it out at that point(i use this same exact thing in a larger patch and, for some reason, it doesn't have the same problem so i'm sure there's a fix just didn't have time to figure it out right away for this thread).

cheers for that duder il try n take a look at them tonight if not tomoro. im also going to give it a go with groove~ and see which comes out best. the whole line~ thing has been hurting my brain a lot hehe. im also going to work out a way to incorporate the 2d.wave~ object.

sorry if im bein stupid here but the .maxpat files will only open as text and i cant open them as patchers. im using 4.5.7 (on XP *urgh*) i imagine that might be somethin to do with it probably should have mentioned it before

oh sorry, ok, thanks for clarifying, you're not being stupid, Max5 can't be converted to Max4(unless you use the special converter that Fredrik Olofsson wrote called MaxPat:

http://www.fredrikolofsson.com/pages/code-sc.html

but even then, it can be tricky since i've used a couple things specific only to Max5, so i will convert the patch to Max4 format and reupload it just a bit later.

oh sorry, ok, thanks for clarifying, you're not being stupid, Max5 can't be converted to Max4(unless you use the special converter that Fredrik Olofsson wrote called MaxPat:
http://www.fredrikolofsson.com/pages/code-sc.html    )

but even then, it can be tricky since i've used a couple things specific only to Max5, so i will convert the patch to Max4 format and reupload it just a bit later.


ok, here ya go(i used frederik's converter, what an amazing, smart tool! only had to change one slider to a multislider to get float-output and the converter even recommended I do that).

anyways, you're probably well on your way with some other method but in case it could still help, i've attached both files in older Max4.6.3 '.pat' format for ya here. Start by playing with samplecutDev.pat and go from there.

the funny thing is i completely rebuilt the patch almost from scratch using groove~ instead of play~ and multislider instead of the matrixctrl - far simpler! now i cant even remember how the other process works... now the patch works in theory but it never stays in time! how do i deal with the timing skipping constantly? iv had this with patches before yet other peoples patches quite often run smoothly... anyway here it is, not annotated really but fairly self evideny just load a sample, press go and play about with the multisliders and loops!

cheers to rabidraja too i will check out ur patch today

the funny thing is i completely rebuilt the patch almost from scratch using groove~ instead of play~ and multislider instead of the matrixctrl - far simpler! now i cant even remember how the other process works... now the patch works in theory but it never stays in time! how do i deal with the timing skipping constantly? iv had this with patches before yet other peoples patches quite often run smoothly... anyway here it is, not annotated really but fairly self evideny just load a sample, press go and play about with the  multisliders and loops!
cheers to rabidraja too i will check out ur patch today


ah, cool, i used to do it sort of like that... except you've got some unecessary double-triggering of events... i'm not really sure where to begin explaining so if you just take a look at the attached mod i made of your patch it'll be easier(...and i didn't spend alot of time on it so there may be quite a bit i missed...). it doesn't seem to skip beats for me now, but you may need to build an easier, more accessible UI that helps you divide your buffer length by the appropriate amount according to BPM, etc.(or perhaps set your tempo according to file-length).....

...also, check out the 'replace' message for buffer~ and, i didn't add it, but check out the 'trigger' object for sending messages in a specific order.

in any case, you're experimenting with all the right stuff.

nice one dude i like your patch and i like what u did to mine... it doesnt exactly seem to skip anymore but each time it loops round there are variations... iv been testing it with one sample mainly, i ought to test it with quite different samples. my next steps are to build a HPF/LPF for it that can be MIDI controlled and then duplicate the patch and stick a crossfader inbetween...

i like the touch with the buffer~ info~... i think i need to make a few tweaks so that any tempo can be entered and dealt with accordingly

nice one dude i like your patch and i like what u did to mine... it doesnt exactly seem to skip anymore but each time it loops round there are variations... iv been testing it with one sample mainly, i ought to test it with quite different samples. my next steps are to build a HPF/LPF for it that can be MIDI controlled and then duplicate the patch and stick a crossfader inbetween...
i like the touch with the buffer~ info~... i think i need to make a few tweaks so that any tempo can be entered and dealt with accordingly


ah, good, glad it helped. sounds like you know what you want and you're well on your way. just one more thing, it sounds like you might be setting up a DJ like setup(crossfading two sources with beat-cut-up and filtering). Just in case you're looking for control that is similar to a DJ mixer, remember that you may want a High-SHELF-filter and Low-SHELF-filter instead of High-PASS and Low-PASS(depends on if you want to be able to cut the highs and lows or be able to get that classic high/low-pass filter sweep sound; if you like the filter-sweeps, high/low-pass is great, but if you're looking to equalize quickly the way DJ mixers allow you to, high/low-shelf is more appropriate).

trouble controlling play~ with lists to line~