Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Julian Brooks]

Hi Fede,

Apologies, I should've been clearer.

The pd-messages tutorial you posted a link to, the patches require fd-lib.

If it's on deken, it's worth announcing (I'd say, though there's no
obligation).

Lib looks good, thanks for sharing.

(other stuff's up to you:)

All the best,

Julian


>Hi Julian,

>Thanks! Do you mean I should announce fd_lib on the list? And that I
should work on more pd-message or different kinds of documentation?

>I am a bit shy about fd_lib since it's not a single purpose library and
has a bunch of stuff that I compiled over the years; I put it up in deken
just for my own >convenience, cause I use it often.

>(also, fd_lib is quite a misnomer since it gets confused with file
descriptor library, and there's anything but that, hah)

>In any case, I really appreciate your support!!

>Best,

>Fede

fdch.github.io

On Feb 23, 2020, at 6:02 PM, Julian Brooks  wrote:


Maybe should add requires the 'fd_lib' too.
Interesting stuff though, +1 for more documentation

>
> https://github.com/fdch/pd-messages
>
>
On Sun, 23 Feb 2020 at 23:03, Julian Brooks  wrote:

> Maybe should add requires the 'fd_lib' too.
> Interesting stuff though, +1 for more documentation
>
>>
>> https://github.com/fdch/pd-messages
>>
>>
>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Julian Brooks]

Maybe should add requires the 'fd_lib' too.
Interesting stuff though, +1 for more documentation

>
> https://github.com/fdch/pd-messages
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Fede Camara Halac]

What old pd-msg examples? 

I did bring together several undocumented pd messages a while ago, but I am 
probably missing some stuff :) 

https://github.com/fdch/pd-messages

and there was wiki: http://puredata.info/community/pdwiki/PdInternalMessages/

(Pd has the "more.arrays" patch also)



>> On Feb 20, 2020, at 7:09 AM, Christof Ressi  wrote:
> 
> Yes. Pd extended also had something like "all about arrays", IIRC.
> 
>> On 20.02.2020 13:05, Dan Wilcox wrote:
>> It would be cool if the old pd-msg examples could be used as a base for 
>> this...
>> 
>>> On Feb 19, 2020, at 3:00 PM, pd-list-requ...@lists.iem.at wrote:
>>> 
>>> Date: Wed, 19 Feb 2020 15:00:23 +0100
>>> From: Christof Ressi 
>>> To: Pd-List 
>>> Subject: Re: [PD] [r pd-dsp-started] was: Re: samplerate~
>>> Message-ID: <51905e01-13e5-df8a-e67c-2152c3a65...@christofressi.com>
>>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>>> 
>>>> I honestly get lost in most of the internal messages and forget which 
>>> ones are "public" and which aren't.
>>> 
>>> To be fair, "pd-dsp-started" / "pd-dsp-stopped" are not mentioned in the 
>>> change log. I also discovered them by accident (probably from reading 
>>> the [samplerate~] help patch).
>>> 
>>> It would be cool if there was a central place where all (public) Pd and 
>>> canvas messages are documented. The canvas messages are especially messy 
>>> because they are currently split across several help patches and 
>>> examples...
>>> 
>>> Christof
>> 
>> 
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Christof Ressi]

Yes. Pd extended also had something like "all about arrays", IIRC.

On 20.02.2020 13:05, Dan Wilcox wrote:
It would be cool if the old pd-msg examples could be used as a base 
for this...


On Feb 19, 2020, at 3:00 PM, pd-list-requ...@lists.iem.at 
<mailto:pd-list-requ...@lists.iem.at> wrote:


Date: Wed, 19 Feb 2020 15:00:23 +0100
From: Christof Ressi <mailto:i...@christofressi.com>>

To: Pd-List mailto:pd-list@lists.iem.at>>
Subject: Re: [PD] [r pd-dsp-started] was: Re: samplerate~
Message-ID: <51905e01-13e5-df8a-e67c-2152c3a65...@christofressi.com 
<mailto:51905e01-13e5-df8a-e67c-2152c3a65...@christofressi.com>>

Content-Type: text/plain; charset="windows-1252"; Format="flowed"


I honestly get lost in most of the internal messages and forget which

ones are "public" and which aren't.

To be fair, "pd-dsp-started" / "pd-dsp-stopped" are not mentioned in the
change log. I also discovered them by accident (probably from reading
the [samplerate~] help patch).

It would be cool if there was a central place where all (public) Pd and
canvas messages are documented. The canvas messages are especially messy
because they are currently split across several help patches and
examples...

Christof



Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>



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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Dan Wilcox]

It would be cool if the old pd-msg examples could be used as a base for this...

> On Feb 19, 2020, at 3:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Date: Wed, 19 Feb 2020 15:00:23 +0100
> From: Christof Ressi mailto:i...@christofressi.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] [r pd-dsp-started] was: Re: samplerate~
> Message-ID: <51905e01-13e5-df8a-e67c-2152c3a65...@christofressi.com 
> <mailto:51905e01-13e5-df8a-e67c-2152c3a65...@christofressi.com>>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
> 
>> I honestly get lost in most of the internal messages and forget which 
> ones are "public" and which aren't.
> 
> To be fair, "pd-dsp-started" / "pd-dsp-stopped" are not mentioned in the 
> change log. I also discovered them by accident (probably from reading 
> the [samplerate~] help patch).
> 
> It would be cool if there was a central place where all (public) Pd and 
> canvas messages are documented. The canvas messages are especially messy 
> because they are currently split across several help patches and 
> examples...
> 
> Christof


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Christof Ressi]

> I honestly get lost in most of the internal messages and forget which 
ones are "public" and which aren't.


To be fair, "pd-dsp-started" / "pd-dsp-stopped" are not mentioned in the 
change log. I also discovered them by accident (probably from reading 
the [samplerate~] help patch).


It would be cool if there was a central place where all (public) Pd and 
canvas messages are documented. The canvas messages are especially messy 
because they are currently split across several help patches and 
examples...


Christof

On 19.02.2020 13:30, Dan Wilcox wrote:
Hah, then I'm wrong. If it's documented, it's canon! I honestly get 
lost in most of the internal messages and forget which ones are 
"public" and which aren't.


No, the regression isn't much different, it's more that things such as 
"dynamic patching" were never really intended form the start and 
became canon, to some extent.


On Feb 19, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at 
<mailto:pd-list-requ...@lists.iem.at> wrote:


Date: Wed, 19 Feb 2020 10:46:07 +0100
From: "Peter P." <mailto:peterpar...@fastmail.com>>

To:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
Subject: Re: [PD] [r pd-dsp-started] was: Re:  samplerate~
Message-ID: <20200219094607.tsx4tjipkr32y...@fastmail.com 
<mailto:20200219094607.tsx4tjipkr32y...@fastmail.com>>

Content-Type: text/plain; charset=us-ascii

* Dan Wilcox mailto:danomat...@gmail.com>> 
[2020-02-19 10:38]:
I would also point out that internal messages such as pd-dsp-started 
don't really come with an expected behavior for user patches. Saying 
how it works is a "bug" belies that fact that I don't believe it was 
ever intended to be used for this and just because it can be grabbed 
via a [r] also doesn't guarantee anything.

The method you point out is shown in the help patch of [samplerate~]
without any reference that it should be considered a bug or temporary
measure.

This is also why it's so hard to change almost *any* behavior within 
Pd as you can never really be 100% certain you aren't breaking 
someone's end use case.
Do you feel this regression condition is much different in other 
software?


best, P



Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>




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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Dan Wilcox]

Hah, then I'm wrong. If it's documented, it's canon! I honestly get lost in 
most of the internal messages and forget which ones are "public" and which 
aren't.

No, the regression isn't much different, it's more that things such as "dynamic 
patching" were never really intended form the start and became canon, to some 
extent.

> On Feb 19, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Date: Wed, 19 Feb 2020 10:46:07 +0100
> From: "Peter P." mailto:peterpar...@fastmail.com>>
> To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
> Subject: Re: [PD] [r pd-dsp-started] was: Re:  samplerate~
> Message-ID: <20200219094607.tsx4tjipkr32y...@fastmail.com 
> <mailto:20200219094607.tsx4tjipkr32y...@fastmail.com>>
> Content-Type: text/plain; charset=us-ascii
> 
> * Dan Wilcox mailto:danomat...@gmail.com>> [2020-02-19 
> 10:38]:
>> I would also point out that internal messages such as pd-dsp-started don't 
>> really come with an expected behavior for user patches. Saying how it works 
>> is a "bug" belies that fact that I don't believe it was ever intended to be 
>> used for this and just because it can be grabbed via a [r] also doesn't 
>> guarantee anything. 
> The method you point out is shown in the help patch of [samplerate~]
> without any reference that it should be considered a bug or temporary
> measure.
> 
>> This is also why it's so hard to change almost *any* behavior within Pd as 
>> you can never really be 100% certain you aren't breaking someone's end use 
>> case.
> Do you feel this regression condition is much different in other software?
> 
> best, P


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Christof Ressi]

I would also point out that internal messages such as pd-dsp-started don't 
really come with an expected behavior for user patches.
I have to second Peter: the "pd-dsp-started" message is a public, 
documented message! It's just that not many people know it exists :-) 
Judging from the [samplerate~] help patch, the message has been added in 
Pd 0.47.


Christof

On 19.02.2020 10:46, Peter P. wrote:

* Dan Wilcox  [2020-02-19 10:38]:

I would also point out that internal messages such as pd-dsp-started don't really come 
with an expected behavior for user patches. Saying how it works is a "bug" 
belies that fact that I don't believe it was ever intended to be used for this and just 
because it can be grabbed via a [r] also doesn't guarantee anything.

The method you point out is shown in the help patch of [samplerate~]
without any reference that it should be considered a bug or temporary
measure.


This is also why it's so hard to change almost *any* behavior within Pd as you 
can never really be 100% certain you aren't breaking someone's end use case.

Do you feel this regression condition is much different in other software?

best, P



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




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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Peter P.]

* Dan Wilcox  [2020-02-19 10:38]:
> I would also point out that internal messages such as pd-dsp-started don't 
> really come with an expected behavior for user patches. Saying how it works 
> is a "bug" belies that fact that I don't believe it was ever intended to be 
> used for this and just because it can be grabbed via a [r] also doesn't 
> guarantee anything. 
The method you point out is shown in the help patch of [samplerate~]
without any reference that it should be considered a bug or temporary
measure.

>This is also why it's so hard to change almost *any* behavior within Pd as you 
>can never really be 100% certain you aren't breaking someone's end use case.
Do you feel this regression condition is much different in other software?

best, P



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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Dan Wilcox]

I would also point out that internal messages such as pd-dsp-started don't 
really come with an expected behavior for user patches. Saying how it works is 
a "bug" belies that fact that I don't believe it was ever intended to be used 
for this and just because it can be grabbed via a [r] also doesn't guarantee 
anything. This is also why it's so hard to change almost *any* behavior within 
Pd as you can never really be 100% certain you aren't breaking someone's end 
use case.

> On Feb 18, 2020, at 11:57 PM, pd-list-requ...@lists.iem.at wrote:
> 
> If, say, you want to send one and only one bang to [switch~] so as to graph
> tables when DSP starts, then [r pd-dsp-started] is only useful if you
> spigot-out future bangs/saves/etc, otherwise you are graphing tables on
> every save...
> 
> It's a feature if you use it for randomness, say, to randomize seeds
> according to when dsp on/off switching or graph redrawing falls, say linked
> with a [timer] object :)
> 
> Perhaps [r pd-dsp-started] should only send bangs when dsp starts or stops,
> and not when the dsp graph is redrawn.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Christof Ressi]

Toggle DSP button ON, aka: ";pd dsp 1"

Then just catch "pd dsp 1"?

Anyway, technically, all those cases are the same: DSP stops, the DSP 
graph is rebuilt, DSP continues.


I think your specific use case is not so much about the fact that DSP 
has started, but more about that the *user* has started DSP.


Christof

On 19.02.2020 00:21, ffdd cchh wrote:

What do you consider a "real" start of DSP?

Toggle DSP button ON, aka: ";pd dsp 1"



Actually, I'm rather asking myself whether it's necessary that saving triggers 
a rebuilt of the DSP graph...

I believe connections need to be re-asserted/ordered so as to re-draw
the graph. Same thing happens with non-tilde objects on canvas.

To add to your question: if no tilde object was touched/moved (or even
exists on a patch) why would the dsp graph be rebuilt on save?



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




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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[ffdd cchh]

> What do you consider a "real" start of DSP?

Toggle DSP button ON, aka: ";pd dsp 1"


> Actually, I'm rather asking myself whether it's necessary that saving 
> triggers a rebuilt of the DSP graph...

I believe connections need to be re-asserted/ordered so as to re-draw
the graph. Same thing happens with non-tilde objects on canvas.

To add to your question: if no tilde object was touched/moved (or even
exists on a patch) why would the dsp graph be rebuilt on save?



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

Re: [PD] [r pd-dsp-started] was: Re: samplerate~

[Christof Ressi]

If DSP is on, you get a bang. If it's off, you won't.
Yes, that's pretty much expected, I guess. After all, it's not 
[savebang] ;-)
Perhaps [r pd-dsp-started] should only send bangs when dsp starts or 
stops, and not when the dsp graph is redrawn. 

When the DSP graph gets rebuilt, DSP *does* stop and start (again).
even though I do understand that, for a tiny moment, the dsp needs to 
be off behind the scenes
It doesn't matter how much time passes between stopping and starting 
DSP, the point is that the DSP graph has or might have changed and 
"pd-dsp-started" will report it.


If, say, you want to send one and only one bang to [switch~] so as to 
graph tables when DSP starts

What do you consider a "real" start of DSP?

Actually, I'm rather asking myself whether it's necessary that saving 
triggers a rebuilt of the DSP graph...


Christof

On 18.02.2020 23:57, ffdd cchh wrote:

It depends.
If DSP is on, you get a bang. If it's off, you won't.

So, If I am expecting a bang because I saved and DSP is off, it just 
bugs me that no bang is sent :)


If, say, you want to send one and only one bang to [switch~] so as to 
graph tables when DSP starts, then [r pd-dsp-started] is only useful 
if you spigot-out future bangs/saves/etc, otherwise you are graphing 
tables on every save...


It's a feature if you use it for randomness, say, to randomize seeds 
according to when dsp on/off switching or graph redrawing falls, say 
linked with a [timer] object :)


Perhaps [r pd-dsp-started] should only send bangs when dsp starts or 
stops, and not when the dsp graph is redrawn.


In any case, I think it's the misnomer what's confusing me. I realize 
that saving redraws the dsp graph, but I don't see why the dsp would 
"start" if it was already switched "on", even though I do understand 
that, for a tiny moment, the dsp needs to be off behind the scenes.



On Tue, Feb 18, 2020 at 5:30 PM IOhannes m zmölnig > wrote:


On 2/18/20 10:21 PM, ffdd cchh wrote:
> The bug/feature with [r pd-dsp-started] is that you'll get a bang
> every time you save the patch,


it's neither a bug nor a feature.
the DSP-graph is re-built when the patch is saved, and so the
"pd-dsp-started" is emitted.

> so it's not very useful while patching

how so?

(a [metro] will also send bangs while patching, and yet it is
useful in
live-coding contexts.)

gmsdtr
IOhannes

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



--
fdch.github.io 

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