Hi, been working on a delread/write variation as posted on the pd-list with more features, like freezing. I have a single "del~" object (named like this for now) and I can define if it's "in" (write) or "out" (read). This is like other pd objects like [list]. I do this so I can use pd_findbyclass so I can pair objects by delay line name ([del~ in xxx] and [del~ out xxx]). I read that was the way to do it in some other thread here not long ago.
Now, maybe I've seen this weird behaviour before but I can't see what's happening. I have A_GIMME to parse arguments and when trying to print the number of arguments (usually defined as "argc") I don't get the values I expect, but very large and negative ones (what the hell?).
I uploaded my prototype just so you can see this and help me figure out where the problem is => https://github.com/porres/pd-else/blob/master/Classes/Source/del~.c
here's the global setup function for both objects https://github.com/porres/pd-else/blob/master/Classes/Source/del~.c#L290
here in the "del_new" function, if I query for the number of arguments, I get the weird values already, see https://github.com/porres/pd-else/blob/master/Classes/Source/del~.c#L266
why dear god, why? please please please, it's late and I'm losing sleep
thanks
Em qua., 3 de mar. de 2021 às 07:26, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
what's that `t_pd*dummy` supposed to do in the argument list of `del_new`?
no idea, I was trying to copy the structure from x_list.c, it was killing me that it works that but I'm obviously missing something.
why don't you have it in `del_in_new`?
It seems that's not what I have to do either. I copied the structure from x_array.c now and it just doesn't have any t_pd*dummy - other than me ;)
But thanks! Inquiring me about the pertinence of it there was a clear warning that it was the problem :)
funny that it was all working just fine, it was when I tried to add "flags" and parse them that things got weird...
cheers
On 3/3/21 12:12 PM, Alexandre Torres Porres wrote:
Em qua., 3 de mar. de 2021 às 07:26, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
what's that `t_pd*dummy` supposed to do in the argument list of `del_new`?
no idea, I was trying to copy the structure from x_list.c, it was killing me that it works that but I'm obviously missing something.
well, "list" is a very special symbol in Pd. that's why it requires special handling when using it as an object-name. hence the "t_pd*dummy" hack in x_list.c
(btw, that's also the reason why zexy's [l] object (aka [lister]) has such a stupid (long) name - i just couldn't make it work in a sane way with the proper name "list". a good thing this is now, that Pd has a [list] object which is slightly incompatible).
It seems that's not what I have to do either. I copied the structure from x_array.c now and it just doesn't have any t_pd*dummy - other than me ;)
[array] is not a special symbol. that's why it is a working template for any such code.
funny that it was all working just fine, it was when I tried to add "flags" and parse them that things got weird...
i doubt it (that is: iff you also had any arguments) having that extra "t_pd*" argument shifts the argument-list by 4 bytes, making the values invalid.
usually this gets caught by the compiler. however, since the constructor-functions arguments are established at run-time (as opposed to compile-time), the code of Pd and friends is full of function-casting, which very efficiently hides such problems.
gmsard IOhannes
-
Alexandre Torres Porres -
IOhannes m zmoelnig -
IOhannes m zmölnig