Beware:  when mixing symbols and floats in parsed argument lists, Pd will

send all the symbol arguments first, then the floats - not necessarily in the order that the arguments appear in the Pd message. Has that ever been documented anywhere other than the logic in m_class.c? -Jonathan

On Monday, January 18, 2016 12:32 PM, Miller Puckette <msp@ucsd.edu> wrote:

It's fine to just use (t_symbol *) for function arguments.

The only reason there's a separate "t_floatarg" is that some 90-s era compilers weren't able to pass single-precision floats as function arguments. I don't think we'll ever see that happen again but there's no reason to go through and take it all out either.

Beware:  when mixing symbols and floats in parsed argument lists, Pd will send all the symbol arguments first, then the floats - not necessarily in the order that the arguments appear in the Pd message.

cheers Miller

On Mon, Jan 18, 2016 at 12:01:44PM -0500, Ricky Graham wrote:

Hello,

Is there a symbol equivalent to t_floatarg when writing an object in C? I’d like to pass a symbol on creation.

All the best,

Ricky _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

It's fine just to store the pointer to the t_symbol - the contents won't be changed or relocated.

cheers M

On Mon, Jan 18, 2016 at 02:28:09PM -0500, Ricky Graham wrote:

O.K., if I am passing a list of symbols and floats, is it best practice to store a symbol in a char array for future use? I’m trying to post the args to the console.

Hi all,

Is there any reason why passing a symbol arg to determine the amount of outlets on object creation would work in extended but not in vanilla? Both compile and create successfully but for whatever reason the symbol arg of my object has no effect on the number of outlets in vanilla. I’m using sprintf to parse and identify symbols passed from the pd patch; would that cause any issues?

All the best,

Ricky

On Jan 18, 2016, at 2:37 PM, Miller Puckette msp@ucsd.edu wrote:

It's fine just to store the pointer to the t_symbol - the contents won't be changed or relocated.

cheers M

On Mon, Jan 18, 2016 at 02:28:09PM -0500, Ricky Graham wrote:

...

O.K., if I am passing a list of symbols and floats, is it best practice to store a symbol in a char array for future use? I’m trying to post the args to the console.

Hi list,

I’ve been working with 16 to 64 grain voices using [clone] in 0.47-1 on El Capitan 10.11.6 with an RME FF400 (FireWire). At various points, my audio card is losing sync and then drops out altogether. The card appears to be working fine with Pd-Extended 0.43 / usual DAWs, etc. This appears to be an issue unique to [clone] usage / 0.47-1, perhaps due to the maximum amount of voices, although the overhead appears to be minimal.

Anyone else having similar issues with their audio interface and Pd-0.47-1 or [clone]?

Cheers,

Ricky

it *might* be that pd-extended has somehow dropped this limitation.

not to my knowledge though (though i always wondered why Pd-vanilla has this limitation in the first place). The limitation you are describing doesn't exist in any flavor of Pd.  But I'd strongly advise external developers to write code as if that were a hard limitation of the API.  (Otherwise you'll screw up the parameter types and cause a crash, or at least make the code more difficult for others to read.) -Jonathan

On Monday, February 1, 2016 1:58 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:

On 01/31/2016 12:57 AM, Ricky Graham wrote:

Hi all,

Is there any reason why passing a symbol arg to determine the amount of outlets on object creation would work in extended but not in vanilla? Both compile and create successfully but for whatever reason the symbol arg of my object has no effect on the number of outlets in vanilla. I’m using sprintf to parse and identify symbols passed from the pd patch; would that cause any issues?

i'm pretty sure that miller is right and that there are no real differences between Pd and Pd-X regarding symbol parsing.

the *only* thing i could think of is: Pd has a built-in limitation that requires (for typechecked arguments) that all symbols come before floats. so you cannot do the following (using class_addcreator() instead of class_new() or brevity):

class_addcreator((t_newmethod)foo_new, gensym("foo"), A_FLOAT, A_SYMBOL, 0);

instead you *must* do either

class_addcreator((t_newmethod)foo_new, gensym("foo"), A_SYMBOL, A_FLOAT, 0);

or

class_addcreator((t_newmethod)foo_new, gensym("foo"), A_GIMME, 0);

it *might* be that pd-extended has somehow dropped this limitation. not to my knowledge though (though i always wondered why Pd-vanilla has this limitation in the first place)

apart from that: i guess you would have to show your code or more information.

gamrds IOhannes

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list