Forums > MaxMSP

play~ play


kp*
November 20, 2009 | 10:01 am

I have been goofing around with play~

As you know you can play to read forward or backwards, etc. by sending line~ a list. I want to be able to play a whole sound file forwards or backwards and at various different speeds but without having to set things by hand…

So i am using info~ to get a dump of the total buffer time and then using a patch which takes a flag for forward and reverse and flips the list to line so that i can get (start, end, position, dur ) all in a nice tidy list.

So my problem is that:

I am not 100% sure i am always getting things in and out of the subpatcher in the right order (but i think i am! haha)

& (more importantly)

not all my samples play.

So in my patch you can see that "B" works always. Just click the message boxes and it always burps out the sounds.

"A" always works the first time you trigger a sample but clicking any subsequent click is sketchy.

I tried to pare the patch down nice and small and included buffers everyone has (anton.aif, etc)

Does anyone see why this is so iffy? and how i can get this to work all the time? Is there a more elegant way to do this?

110% sure this is just my errors, but i was hoping another pair of eyes would help me sort this out.

cheers,

kp

patch to follow

PS. i hate working with groove~ (which is a pain to jigger inside a poly) (((((don’t ask)))))) … but darn it if groove~ didn’t occasionally seem to sound better than play~ using the same samples! I thought they were both the same (& same quality) only that groove interp-o-lated the loop points (zero interest in looping here)… so i chose play~ which is easier to manage but ….

– Pasted Max Patch, click to expand. –

Tim Lloyd
November 20, 2009 | 10:35 am

If you look at the printed output from [p rev] there is no comma after the first float. Line only responds to a message with the format [value, value value].

Might be good to use sprintf to format the message instead of pack, then you can make sure the comma is there.

Oh yeah, about groove~, if you play back a sine wave using groove~ play~ wave~ and index~ and hook them up to spectroscopes, you can see that index~ has no artifacts (it does no interpolation) and groove~ has significantly less artifacts than play~. Wave~ really isn’t ideal for long sample playback, and seems to have some prominent artifacts.


jvkr
November 20, 2009 | 12:10 pm
Quote:
Line only responds to a message with the format [value, value value].

Not entirely true. Line responds to individual values by jumping to that value and to a list by moving to the first value in the second value amount of time (a list can have a multiple of two amount of items).

Quote:
Might be good to use sprintf to format the message instead of pack, then you can make sure the comma is there.

The use of sprintf (as well as combine) should be limited to an absolute minimum, as memory used by the object is not freed. In this case a message [$1, $2 $3] would do.


Tim Lloyd
November 20, 2009 | 12:41 pm

Yeah, you’re right about line/line~

Useful to know that about sprintf and combine, I had no idea! I’ll stop using them when messages are appropriate. Are there any more really inneficient objects? It’s really useful to know.


kp*
November 20, 2009 | 2:22 pm

grr…. silly syntax faux pas! well, sometimes it just takes a fresh pair of eyes.

so how is this, then? i just stuck a ($1, $2 $3) at the output of the [p rev] patcher and it seems to work.

– Pasted Max Patch, click to expand. –

jvkr
November 20, 2009 | 3:17 pm

The five numbers at A go to a [t b i] object. This means that first a message is sent, and then, for the next event, the switch is set. Another way of thinking of order is first set the switch and then do the rest with a [t i b].


kp*
November 20, 2009 | 3:35 pm

I wasn’t quite sure what order i should do that in. I might have changed that a few times. I could not figure out which way was most reliable. I’ll switch it to how you outlined that above and see what that is like. Thanks.


kp*
November 20, 2009 | 3:45 pm

That does some more reliable. Thanks. Anyway this (so far) is for my own education. I am gonna work on the pitch shifting stuff and then add some pan and poly~ action. I just want to get my playback engine as good as i can get it b4 i head in that direction.

– Pasted Max Patch, click to expand. –

kp*
November 21, 2009 | 9:06 am

Okay I stuffed this sucka into a poly and hit it with the target/counter pair…. but suddenly it doesn’t work at all. I just get a DC click in my speakers. I have used this method with poly~ and play~ before and it worked. Something i have adjusted here has thrown it off course. But i don’t see anything wrong with the patch. Any ideas?

– Pasted Max Patch, click to expand. –

stefantiedje
December 6, 2009 | 4:15 pm

Your bug is inside the poly~ (samply2) which I can’t look at. But the main problem in your first and later patches always had been order. If you first put values into the right inlets of a switch, and then decide to switch, it won’t work as expected…
I bet its along these lines…

Stefan


kp*
December 7, 2009 | 3:35 pm

Yes. You are correct. I have changed the order and it works as expected.

Viewing 11 posts - 1 through 11 (of 11 total)