I thought about it, but the the problem is that I'd like the signal to update the incoming value even if it is 0...

so it doesn't quite make it.

thanks

2015-02-24 14:20 GMT-03:00 Joe White white.joe4@gmail.com:

Hey Alexandre,

Does this do want you want? Toggles between a signal input converted to control rate and a default value (if the signal is 0)

Cheers, Joe

On 24 February 2015 at 17:08, Alexandre Torres Porres porres@gmail.com wrote:

...

hi, trying to make an abstraction here that loads a number argument into an audio signal chain, but I'd like to update the argument to whatever is coming from an [inlet~], but then I'd like to load back the argument whenever there is no signal connected to this inlet.

The only way to do this is if I know wether there was something connected to this inlet or not, and I believe that's impossible in a subpatch/abstraction, right?

So, the only way out would be compiling a new object, huh?

thanks

---

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

-- Follow me on Twitter @diplojocus

I think that even in the case of an external, it's difficult to know whether there's a signal connected to a signal inlet, or not. I think Eric Lyon's externals do what you want (maintain their signal inlet even if they're provided with an argument), but haven't understood how he does that (even though I've read his book about externals...).

Converting an inlet to a control inlet if there's an argument provided, is quite easy, on the contrary.

On Tue, Feb 24, 2015 at 7:31 PM, Alexandre Torres Porres porres@gmail.com wrote:

So that's why I guess it has to be an object...

Moreover, some objects in pd have this interesting behavior.

When you have an argument in [*~], for example, it turns the second inlet into a data only inlet (no signal).

I found this behaviour even in some externals like [>~] in zexy, so I wonder if this is some restriction of pd objects itself, or if it was just a design option that was replicated in zexy on purpose.

If I have to do this as an object, I'd like it to maintain a signal inlet even though I have number argument. So I hope there's nothing "weird" in Pd that doesn't allow this to happen.

cheers

2015-02-24 14:26 GMT-03:00 Alexandre Torres Porres porres@gmail.com:

I thought about it, but the the problem is that I'd like the signal to

...

update the incoming value even if it is 0...

so it doesn't quite make it.

thanks

2015-02-24 14:20 GMT-03:00 Joe White white.joe4@gmail.com:

Hey Alexandre,

...

Does this do want you want? Toggles between a signal input converted to control rate and a default value (if the signal is 0)

Cheers, Joe

On 24 February 2015 at 17:08, Alexandre Torres Porres porres@gmail.com wrote:

...

hi, trying to make an abstraction here that loads a number argument into an audio signal chain, but I'd like to update the argument to whatever is coming from an [inlet~], but then I'd like to load back the argument whenever there is no signal connected to this inlet.

The only way to do this is if I know wether there was something connected to this inlet or not, and I believe that's impossible in a subpatch/abstraction, right?

So, the only way out would be compiling a new object, huh?

thanks

---

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

-- Follow me on Twitter @diplojocus

---

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

On Tue, Feb 24, 2015 at 7:52 PM, Alexandre Torres Porres porres@gmail.com wrote:

"I think that even in the case of an external, it's difficult to know whether there's a signal connected to a signal inlet, or not (...) I think Eric Lyon's externals do what you want"

I guess it can be tricky, but not impossible. I'd be really surprised and blown away if it turned out to be impossible.

I sent to the list about a year and a half ago, when I was writing some externals, asking about this, and I remember Miller gave a suggestion, saying it's not the most elegant but it might work. Can't remember what it was, as I never used it, but if you search the list archives, you might find it. Max has a routine that checks whether there's is a signal connected to an inlet, and this way you can choose between the argument or the incoming signal. But Pd doesn't have that afaik..

And I guess it is actually impossible to work this out in a patch, huh? I wouldn't be surprised...

I'm pretty sure that yes, it's impossible. But it would be nice if someone can prove us wrong here..

thanks

I'm actually interested in knowing whether there's a signal connected to the inlet of an abstraction.

I need it so I can automatically switch between the argument loaded in the abstraction and whatever is going to that inlet from a signal connection.

But I guess it is kinda impossible to it in a patch... so it may be only possible as an external...

"*all of Pd's binops (e.g. [+~]) take an optional argument, and the type*

*of the second inlet depends on the existance of this argument (ifthere is no argument, you get a signal inlet, if there is an argument**you get a message inlet).*"

but is it possible to write an external with a different behaviour like I need?

"*finally: i haven't looked at your abstraction, but i guess the problem*

*you are facing is to distinguish between no argument and the default"0" argument. it's possible to do this as a vanilla abstraction. check**the list archives for examples.*"

that seems like a separate issue, one that I actually care about, so I'll maybe check it.

cheers

2015-02-25 5:25 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-02-24 18:52, Alexandre Torres Porres wrote:

...

"I think that even in the case of an external, it's difficult to know whether there's a signal connected to a signal inlet, or not (...) I think Eric Lyon's externals do what you want"

I guess it can be tricky, but not impossible.

i think you are asking the wrong question here: you are not at all interested in whether an object has a signal connected or not, but only whether you can provide a "default signal".

while the former might be tricky, the latter might not be.

otoh, i'm not entirely sure whether you "should" really want what you are asking for. in a "max compat" sense it might make sense, but it's not very Pd'ish: all of Pd's binops (e.g. [+~]) take an optional argument, and the type of the second inlet depends on the existance of this argument (if there is no argument, you get a signal inlet, if there is an argument you get a message inlet).

finally: i haven't looked at your abstraction, but i guess the problem you are facing is to distinguish between no argument and the default "0" argument. it's possible to do this as a vanilla abstraction. check the list archives for examples.

fgmasdr IOhannes

PS: as far as zexy is concerned, i will keep it as Pdish as possible. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQIcBAEBCAAGBQJU7YcEAAoJELZQGcR/ejb4ZoYP/Ao0qYb0voK1j8BWVFoBrCgy tSbO3yYcO/WzFQBEc6ZBWf5CooRjWGnI/3xO0ZUXyfNlv073O49ra4Oe1NoPRlEQ P37Z8jwACO1cBel8lBVlZ80l3WsKGKRf7UynF3sVI5HJaIjOK5I5ssb6FNWl2cM3 FFluN226XXqCjtdYMfeRkIalEpH9BVIzflL+H3kZ9oBUA9ZHUVQ1ifpIOsxrn6df Z/K1uwmNKYauwUwqvpm2ARUbAyINoD1WiagITE3GOVcSddsO9OnJYiZVnOH8XulU z9AfAwFWjQPI8fTsvORWBDBhDUce3WFOuZ4ZCyqzVw9RQlmMq1Q4HYGYoPBinOM1 vYR92sqEOHrZhN8nal6rTsYCmy5BLJeprU7mWrxr+GrA5CLv2fvBbL3E6uTD9Xz9 Q5+lR+4FLexxVDDIAI7fnM+RADYLWTQuCytENPiUDzcfmv/g+KWGIXH2+yvu4/UR j+1wGUyAfHYmL59GEpla0ZmQonkN/1hyq3yBYlo8Oz0+D038ixjRu8LpB4pTHDFm KCiuOo35vkUfyZz2gCU8/5JE9aXr/fjaYt3VLgxpbCRjgRoW2Y0wtJosNl/4DCeK 61RKMaZPYEjY19K8k3Pi0X/xSdep7dAClldT+KF5FkbpBjGdUG9rJcEMFtteYPKz g7Slg3igjpG4dXBG5wFK =y1hh -----END PGP SIGNATURE-----

---

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

Hi Alexandre,

Some cyclone objects (bitand~, bitor~, bitxor~, pong~, Scope~) change their behaviour depending upon a signal is connected to an inlet.

It uses functionality outside the official Pd API (m_pd.h), so depending on your point of view they are illegal or just unstable. The part of the framework providing the functionality is actually called 'unstable' :-).

Fred Jan

So that's why I guess it has to be an object...

Moreover, some objects in pd have this interesting behavior.

When you have an argument in [*~], for example, it turns the second inlet into a data only inlet (no signal).

I found this behaviour even in some externals like [>~] in zexy, so I wonder if this is some restriction of pd objects itself, or if it was just a design option that was replicated in zexy on purpose.

If I have to do this as an object, I'd like it to maintain a signal inlet even though I have number argument. So I hope there's nothing "weird" in Pd that doesn't allow this to happen.

cheers

2015-02-24 14:26 GMT-03:00 Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com>:

I thought about it, but the the problem is that I'd like the signal
to update the incoming value even if it is 0...

so it doesn't quite make it.

thanks


2015-02-24 14:20 GMT-03:00 Joe White <white.joe4@gmail.com
<mailto:white.joe4@gmail.com>>:

    Hey Alexandre, 

    Does this do want you want? Toggles between a signal input
    converted to control rate and a default value (if the signal is 0)

    Cheers,
    Joe

    On 24 February 2015 at 17:08, Alexandre Torres Porres
    <porres@gmail.com <mailto:porres@gmail.com>> wrote:

        hi, trying to make an abstraction here that loads a number
        argument into an audio signal chain, but I'd like to update
        the argument to whatever is coming from an [inlet~], but
        then I'd like to load back the argument whenever there is no
        signal connected to this inlet.

        The only way to do this is if I know wether there was
        something connected to this inlet or not, and I believe
        that's impossible in a subpatch/abstraction, right?

        So, the only way out would be compiling a new object, huh?

        thanks

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




    -- 
    Follow me on Twitter @diplojocus

---

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