Forums > MaxMSP

Error with preset and waveform~

July 12, 2009 | 7:44 pm

I’m having serious problems getting the preset object to behave properly together with waveform~.

All I want is for preset to remember the start and end point of the waveform~, but very often I have to press the stored preset twice to recall the correct values.

Take a look at the enclosed example. I guess this is a bug?

– Pasted Max Patch, click to expand. –

July 12, 2009 | 7:57 pm

Max 5.0.4 OS 10.4.11 and no problems. Although the problem doesn’t really have anything to do with the [waveform~] object seeing as the [preset] is only recording the states of the [number] boxes. Do you definitely get this problem in the stripped down patch you posted or is that just part of a larger patch? It might be an triggering issue as the order of object state recall is undefined (I think). Sorry I can’t be of more help.

lh


July 12, 2009 | 8:03 pm

I think it’s got something to do with waveform~, because if I simplify the patch to just a preset object and to integer boxes, everything works fine (see below).

Yes, I get the error in patch I posted in the first post.

Do you get an immediate, correct update in the selected part of waveform~?

(btw, I am running 5.0.7 and Leopard)

– Pasted Max Patch, click to expand. –

July 12, 2009 | 8:21 pm

Ok, I made a temporary fix by inserting a pipe object between the sample end point, which delays the sample end value slightly. Not sure I understand why this fixes things, though, since I thought the preset object would somehow(?) be "beyond" these kinds of timing issues (if that is indeed what they are):

– Pasted Max Patch, click to expand. –

July 12, 2009 | 8:45 pm
oivindi wrote on Sun, 12 July 2009 21:44
I’m having serious problems getting the preset object to behave properly together with waveform~.

All I want is for preset to remember the start and end point of the waveform~, but very often I have to press the stored preset twice to recall the correct values.

Take a look at the enclosed example. I guess this is a bug?

with preset, you have no control about the order of recall of each item when you recall a preset. That’s one of the reason why you may need sometimes to recall the preset twice. The other reason is that there’s a mechanism embed in waveform~ to make sure that the selection is greater than 0, which can cause similar issue if the new end of selection is before last start of selection and that you recall from the right to the left. I would recommend using pattr or make a list that you send to the selection start inlet.

HTH,


July 12, 2009 | 8:47 pm

Then it does appear to be related to the order that [waveform~] receives the numbers. You could use [defer] or [deferlow] instead of pipe or [pak 0. 0.] both numbers into a list and send it to the third inlet as this will ensure it is triggered when both numbers are present.

lh


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