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