nanoArchae

I'm running into some sort of type casting error with the curve~ object. I'm building a message like "100, 200 50 0.5" through a series of calculations and prepends / appends, but when I finally pass it over to curve~ it spits back an error. If I print the same message and paste the result into a message box and use that on curve~, it works. I'm guessing the message is being treated as one big symbol instead of a list of arguments? Any quick fix?

bad-curve-arguments

i use [pack] to collate the calculations
works fine


> I'm running into some sort of type casting error with the curve~ 

> object. I'm building a message like "100, 200 50 0.5" through a 

> series of calculations and prepends / appends, but when I finally 

> pass it over to curve~ it spits back an error. If I print the same 

> message and paste the result into a message box and use that on 

> curve~, it works. I'm guessing the message is being treated as one 

> big symbol instead of a list of arguments? Any quick fix?

hm, "100, 200 50 0.5" is not one message but actually two, separated 

shot in the dark: check the message box helpfile and read about max 

or post a patch, so we can have a look at where things might go wrong.

it's a little tricky to generate messages with commas in max. but 

"100, 200 50 0.5" is the same as "100 0 0 200 50 0.5"

>
> I'm running into some sort of type casting error with the curve~  
> object. I'm building a message like "100, 200 50 0.5" through a  
> series of calculations and prepends / appends, but when I finally  
> pass it over to curve~ it spits back an error. If I print the same  
> message and paste the result into a message box and use that on  
> curve~, it works. I'm guessing the message is being treated as one  
> big symbol instead of a list of arguments? Any quick fix?
>

hm,  "100, 200 50 0.5" is not one message but actually two, separated  
by a comma.
shot in the dark: check the message box helpfile and read about max  
and commas,
or post a patch, so we can have a look at where things might go wrong.

it's a little tricky to generate messages with commas in max. but  
it's easy to avoid.
"100, 200 50 0.5" is the same as "100 0 0 200 50 0.5"

Thanks, volker. Your suggestion worked. But now I'm experiencing some other strange behavior. The patch only works if I retoggle dac~. Particularly, curve~ won't produce any signal until I disblae dac~ and then re-enable it. I tried moving the dac~ and buffer~ load to the bottom right so it would be evaluated first but no dice. Strange... I will attach the patch so you can all see my abysmal code, heh. (It will prompt you for a wav on load. The message at the top beginning with 'cym' will trigger the patch. The dac~ object is located at the bottom right.) Suggestions appreciated!

> Thanks, volker. Your suggestion worked. But now I'm experiencing 

> some other strange behavior. The patch only works if I retoggle 

> dac~. Particularly, curve~ won't produce any signal until I disblae 

> dac~ and then re-enable it. I tried moving the dac~ and buffer~ 

> load to the bottom right so it would be evaluated first but no 

> dice. Strange... I will attach the patch so you can all see my 

> abysmal code, heh. (It will prompt you for a wav on load. The 

> message at the top beginning with 'cym' will trigger the patch. The 

> dac~ object is located at the bottom right.) Suggestions appreciated!

hi, i just had a quick look at your patch - a little too convoluted 

to be easily debugged. and your screen is obviously a lot bigger than 

but the patch seems to work over here. loadbanging the dac is 

problematic. wouldn't do that, or at least delay it a little bit.

don't know why you want to use curve~ instead of linear playback, but 

the number of repeats is not correct because of the ">=" in the [if] 

> Thanks, volker. Your suggestion worked. But now I'm experiencing  
> some other strange behavior. The patch only works if I retoggle  
> dac~. Particularly, curve~ won't produce any signal until I disblae  
> dac~ and then re-enable it. I tried moving the dac~ and buffer~  
> load to the bottom right so it would be evaluated first but no  
> dice. Strange... I will attach the patch so you can all see my  
> abysmal code, heh. (It will prompt you for a wav on load. The  
> message at the top beginning with 'cym' will trigger the patch. The  
> dac~ object is located at the bottom right.) Suggestions appreciated!
>

hi, i just had a quick look at your patch - a little too convoluted  
to be easily debugged. and your screen is obviously a lot bigger than  
mine...
but the patch seems to work over here. loadbanging the dac is  
problematic. wouldn't do that, or at least delay it a little bit.
don't know why you want to use curve~ instead of linear playback, but  
you'll have your reasons.
the number of repeats is not correct because of the ">=" in the [if]  
statement - use ">" instead.
apart from that, it seems fine.
vb


Bad curve~ arguments