Hi, when using A_GIMME I can test if the type is A_FLOAT or A_SYMBOL, but if I give it a "$1", for instance, it's treated as a float. Now, if I have 'A_DEFSYM' instead of 'A_GIMME', then '$1' is considered as a symbol.
The problem is that I have to check if the first argument of cyclone/play~ is a float or not. If it's a float, then the creation fails and an error is given. If it's a symbol, then it's an array name. But if you have an abstraction ans using '$1' for the table name, the object shouldn't consider it as a float and fail the creation. This is the problem I need to solve.
Thanks
Hi, when using A_GIMME I can test if the type is A_FLOAT or A_SYMBOL, but if I give it a "$1", for instance, it's treated as a float.
Well, it depends on the actual value of "$1". In the case of [cyclone/play~ $1], the "$1" is replaced by its actual value before being passed to the object. A_GIMME (and Pd lists in general) doesn't know anything about dollars or dollarsyms, all list items are either A_FLOAT, A_SYMBOL or A_POINTER.
Now, if I have 'A_DEFSYM' instead of 'A_GIMME', then '$1' is considered as a symbol.
I guess what happens is that you instantiate [cyclone/play~] on a top level canvas (which doesn't have creation arguments), so the value of "$1" is always "0". A_DEFSYM converts non-symbols to an empty symbol.
So there is nothing to worry about. I guess the easiest way is to just use A_SYMBOL, so Pd will automatically give an error if you try to pass it a float. Otherwise use A_GIMME and check manually.
Christof
Em sex., 17 de set. de 2021 às 13:00, Christof Ressi info@christofressi.com escreveu:
I guess what happens is that you instantiate [cyclone/play~] on a top level canvas (which doesn't have creation arguments), so the value of "$1" is always "0". A_DEFSYM converts non-symbols to an empty symbol.
Yes, that's the problem. I should have said it all works fine if this is an abstraction loaded with actual arguments. But I still wonder if there's anything I can do. I do need to use A_GIMME ayway, changing that is not an option.
Otherwise use A_GIMME and check manually.
This is what I'm doing, but if I check if it's a float (illegal), then $1 is a float... so, well, just to be clear, there's no way around this, right?
cheers
Christof
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Yes, that's the problem. I should have said it all works fine if this is an abstraction loaded with actual arguments. But I still wonder if there's anything I can do.
There is: just don't do it :-) It doesn't make sense to use $1 in the context of a top-level canvas (until we get https://github.com/pure-data/pure-data/pull/1064).
I guess you have an abstraction that should also work as a standalone patch. In that case, just don't use creation arguments. Instead you can get the creation arguments from the canvas with [args( -> [pdcontrol] and pass them on to the relevant objects via messages. It's awkward, but there's no other way.
---
The actual problem is that we don't have a way to *forward* creation arguments. Ideally, we should be able to do something like [cyclone/play~ $@], where "$@" would mean "all creation arguments". In case of a root canvas, the list would simply be empty and you wouldn't have any trouble in your object to distinguish both cases.
Christof
Em sex., 17 de set. de 2021 às 17:18, Christof Ressi info@christofressi.com escreveu:
It doesn't make sense to use $1 in the context of a top-level canvas
I know, that's not the case.
I guess you have an abstraction that should also work as a standalone patch.
not really.
The thing is that when you're designing the abstraction, before it exists, when you're bringing it to life, in its creation process, you might be working on it under the top level, and it's annoying to have the object not created.
you can get the creation arguments from the canvas with [args( -> [pdcontrol] and pass them on to the relevant objects via messages. It's awkward, but there's no other way.
yes, we can do that, I know, and I see there's no other way now.
thanks!
oh, by the wayt, in the end [play~ float] was not illegal in MAX, so I just made it create the object in Pd as well :)
Em sex., 17 de set. de 2021 às 23:37, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 17 de set. de 2021 às 17:18, Christof Ressi < info@christofressi.com> escreveu:
It doesn't make sense to use $1 in the context of a top-level canvas
I know, that's not the case.
I guess you have an abstraction that should also work as a standalone patch.
not really.
The thing is that when you're designing the abstraction, before it exists, when you're bringing it to life, in its creation process, you might be working on it under the top level, and it's annoying to have the object not created.
you can get the creation arguments from the canvas with [args( -> [pdcontrol] and pass them on to the relevant objects via messages. It's awkward, but there's no other way.
yes, we can do that, I know, and I see there's no other way now.
thanks!
The thing is that when you're designing the abstraction, before it exists, when you're bringing it to life, in its creation process, you might be working on it under the top level,
I see!
and it's annoying to have the object not created.
IMO, there is no reason why an object should refuse to create if you pass bad values for *optional* creation arguments. It's enough to just post an error message, just like when you pass bad values to the corresponding method.
that's also a good point!
it's just that cyclone follows this max logic and we actually did change some of that from the older versions. Some objects in MAX have obligatory arguments and don't create if you don't give it any arguments. In Max that's fine cause you can still call the help file, in Pd you can't. So we're creating the object anyway in cycclone instead.
In this case I agree the best thing to do would be just to let it create with a bad argument.
But hey, it's nice that a DEFSYM doesn't turn "$1" to a float and complains :) it was nice to learn that.
well, thanks again cheers
Em sáb., 18 de set. de 2021 às 12:38, Christof Ressi info@christofressi.com escreveu:
The thing is that when you're designing the abstraction, before it exists, when you're bringing it to life, in its creation process, you might be working on it under the top level,
I see!
and it's annoying to have the object not created.
IMO, there is no reason why an object should refuse to create if you pass bad values for *optional* creation arguments. It's enough to just post an error message, just like when you pass bad values to the corresponding method.
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Alexandre Torres Porres -
Christof Ressi