I agree. I think the current Pd-extended focused manual could be moved to a Pd-extended location for historical reasons. The "main" Pd FLOSS manual should be Vanilla + links or sections to active forks including the original Pd-extended manual. The current manual could then be refactored/updated and existing links would not be *terribly* broken.
> On May 31, 2021, at 12:00 PM, pd-list-request(a)lists.iem.at wrote:
>
> Message: 1
> Date: Sun, 30 May 2021 18:48:18 -0300
> From: Esteban Viveros <emviveros(a)gmail.com <mailto:emviveros@gmail.com>>
> To: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>>
> Cc: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] Pd FLOSS Manual, what to do with it?
> Message-ID:
> <CAJQqjJQCHRhc6mR4f==uoaJRGBCr3JgqfRZnK=o1W3-ofLmP-g(a)mail.gmail.com <mailto:CAJQqjJQCHRhc6mR4f==uoaJRGBCr3JgqfRZnK=o1W3-ofLmP-g@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> I think the best with Pd Floss is first to elucidate the community about
> Pd-Vanilla and the Forks. The name Pure Data Floss tutorial should be
> relayed in Pd-Vanilla only. In a historical Introduction, it can explain
> the history of creation of Pd, about Pd-Extended death, the actual
> situation and cite Pd forks, like Pd-ceammc and Purr-Data.
>
> After that we can update and even improve Pure Data Floss and it is. If
> Pd-ceammc and Purr-Data communities start thinking about creating a
> FLOSS for your distribution, they can do it with their proper names.
>
> This can avoid a lot of noise in the community and create an environment
> where everyone can choose the Pd software that best suits their needs.
>
> Cheers
> Esteban
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Folks, we're on a roll debating all things related to Pd documentation here
and there and I'm now focusing on the Pd FLOSS Manuals issue.
Pd has this very famous and long lasting FLOSS Manual. It's old and it
tells you how to instal Pd Extended 0.39! So, it's from the extended era
and still references to 'extended objects'. For what I see, it was a Manual
that came to be in the Extended era as a Manual to it. Back in the day we
basically all used just Extended anyway and were mostly oblivious to
Pd Vanilla and its manual.
And by Pd's manual, I mean http://msp.ucsd.edu/Pd_documentation/index.htm
- I know that's called 'Pd Documentation', and that it is confusing, cause
it actually is an 'html Manual' and it refers to itself as "this html
manual". Anyway, this is also something I brought up on github and is not
the issue here..
The point is that there's a conflict and I guess this made sense then, but
it's a problem nowadays. A documentation noise problem. Lots of people seem
to get to it and consider it "the manual for Pd". We're still struggling
with a post Pd Extended issue and what was consolidated in its era but now
sits as ruins. Actually, Pd Vanilla's manual also refers to FLOSS Manuals.
But these days we have something weird, which is simply the fact that Pure
Data has these two manuals. One is the official one, included as part of Pd
Vanilla and its documentation, and this other one, which is terribly
outdated and actually refers to this unsupported and abandoned fork of Pd.
But the point is, one software cannot have two concurring Manuals, even if
both are up to date - that'd be silly. The point of FLOSS is to provide the
one and only official and single Manual for a piece of software. See the
problem? Csound uses FLOSS Manuals as a place to provide its official
manual. It's clearly linked in csound.com. Csound also has the
'Canonical Csound reference manual', which is actually something else and
not to be confused with "The" manual they provide in FLOSS.
So, my point is we have to get rid of one of them and have a single
official one.
Should we then remove the included and official manual from Pd and 'move
it' to FLOSS and completely overhaul that online version?
Or just get rid of the FLOSS version? Well, that is there, and people know
it. Burn it down, purge and disappear with it would be bad.
Well, I don't know, so I'm asking...
Another scenario is that FLOSS can still be around, of course, but as a
museum piece, for those interested in web archeology, as extended is now an
archeological piece of software. No one touches it, it stays there, but we
try to make it clear how that is an old, outdated, unofficial and that Pd
has its own 'real manual. This would help a lot. Or... also, treat it for
what it is, a manual reference for Pd Extended, not Vanilla, and make it
clear how Pd Extended is abandoned and so is this manual.
Other than these, the only option I see is we maintain and update these two
manuals somehow. And I already said how I think that's pointless. I also
don't know who'd do that... but maybe there'd be a way to manage them as
two clearly distinct guides. One would be the 'Canonical Vanilla Manual'
and the other could be 'The Pure Data Manual' (or some other name)? The
question would be, why to do that? What is the advantage in keeping another
FLOSS version around?
The thing I can think people like about the FLOSS version is:
- A) A friendlier look for beginners;
- B) A nice beginner level tutorial;
- C) Support for many externals, external libraries, how to use Arduino and
stuff (more as a tutorial than a 'manual');
These can all be compensated. With 'A)', we can try and make the Pd manual
look nicer maybe? As for the rest, what really seems to be the substance of
this is the fact that it serves as a tutorial.
Well, a tutorial is not necessarily a "Manual".
We can add tutorials to Vanilla too... actually, even though it's based on
Extended, many of the examples there are 'vanilla', so they can be
easily ported and shipped as part of Vanilla!
As for tutorials that use externals. Well, they would really benefit from
an update. But a tutorial is a tutorial, this could live somewhere else.
By the way, tutorials can easily be uploaded to deken and be available from
there. You'd have a tutorial that relies on externals, but that's ok too
(my live electronics tutorial comes as part of the ELSE download)... just
give instructions in the tutorial on how to install the needed libraries
from deken as well...
But if the case is made that we should really keep FLOSS and update it.
Well, maybe we could manage and do that, taking care on how to not overlap
even know I don't know who'd do it, but it'd mean completely rewrite from
scratch and get rid of some of the stuff. That's bad too, as the old
version would be lost (so have it sit as an 'old extended manual'?).
So, in short, possible scenarios include:
1) Forget about floss, tell it's outdated (rename it to pd extended manual
maybe), focus on Vanilla's manual. Bring stuff we miss and like from FLOSS
to current Pd in some new form.
2) 'Move' Pd's manual to a new FLOSS incarnation
3) Keep and manage two versions
My thoughts on these are here, and I think the best scenario is number "1)"
Any other thoughts?
Cheers
Hi
When using "many" data structure scalars, all scalars seem to get
redrawn on certain actions. I initially thought it happens when
appending scalars, but it's appears simply appending a scalar doesn't
trigger it. The time to redraw the scalars seems proportional to
overall number of scalars. This redrawing doesn't seem to cause a CPU
spike, but it creates visual glitches.
I am curious to know what goes on behind the scene. Can this be avoided
or maybe minimized?
This is a video showing the glitch:
https://netpd.org/~roman/tmp/netpd_datastructure_glitch.mp4
Roman
Great !
If your project is to create a fixed-size oscilloscope abstraction, may
be it's a good idea to check also the original discussion and patch
by Ingox
(https://forum.pdpatchrepo.info/topic/11184/colarray-a-graphical-array-where…)
, as my work was mainly to embed it with some extra features (dynamic
patching, properties gui, state saving, mobmuplat export) that make
complexity grow.
J.Y.G.
On 29/05/2021 11:18, hans w. koch wrote:
> thanks jean-yves,
>
> thats some serious wizzardry and it seems that i could build my
> oscilliscope from that :-)
> have to study it a bit more to really understand, whats going on under
> the hood.
>
> in the meantime i built sth with purr data, which has a properties
> dialogue with a colorpicker. for arrays.
> (i wanted sth simple + workable quickly).
> ultimately i think, that would be good to have in pd as well.
>
> also will check out your mob collection, as i am a big fan of
> mobmuplat, which sadly seems dormant but still keeps working on the
> newest iOS.
>
> best
> hans
>
>
>> Am 29.05.2021 um 10:17 schrieb Jean-Yves Gratius <jyg(a)gumo.fr>:
>>
>> Hi hans,
>>
>> You should try my sarray abstraction (based on this discussion
>> https://forum.pdpatchrepo.info/topic/11184/colarray-a-graphical-array-where…)
>>
>> download here https://github.com/jyg/mob/releases/tag/mob-0.1
>>
>> There is some trickery to get an array name with $0 tag, but it's
>> explained
>>
>> J.Y.G.
>>
>>> Re: [PD] is there a way to color the points/curve in an array?
>>> From: "hans w. koch" <hansw.koch(a)gmail.com>
>>> Date: 28/05/2021 à 22:02
>>> To: Pd-List <pd-list(a)lists.iem.at>
>>>
>>> thank you, roman and alexandre, for the pointers!
>>>
>>> it seems, the best option is to wait, till the discussion alexandre
>>> referenced (https://github.com/pure-data/pure-data/pull/711) comes
>>> to fruition.
>>> purr data has implemented such a color picker for arrays, so that
>>> would be the second best option.
>>> i looked into Jmmmp multiarray, but i seemed to be better suited at
>>> displaying static waveforms.
>>> maybe i overlooked something.
>>>
>>> i am (ab)using pd as an eight channel oszilloscope.
>>> things get messy pretty fast without colors.
>>>
>>>
>>>
>>> <oszi8.pd.jpg>
>>>
>>>
>>>> Am 28.05.2021 um 14:59 schrieb Roman Haefeli <reduzent(a)gmail.com>:
>>>>
>>>> On Fri, 2021-05-28 at 14:04 +0200, Roman Haefeli wrote:
>>>>> On Fri, 2021-05-28 at 13:31 +0200, hans w. koch wrote:
>>>>>> using 4 superimposed arrays to show different waveforms (e.g. phase
>>>>>> differences), i was wondering, if there is a way to assign a unique
>>>>>> color to each array, to visually better separate the waveforms.
>>>>>> i found a discussion "[PD] Array Enhancements" about that (and
>>>>>> other
>>>>>> things, like "Hide Array name” - still not working) from 2009 [1]
>>>>>> and
>>>>>> another one "[PD] colored arrays?” from 2007 [2],
>>>>>> but no tangible result - or i missed that, then sorry!
>>>>> As someone mentioned in one of the other threads, you could achieve
>>>>> colored array displays with data structures.
>>>>>
>>>>> An example is here:
>>>>> https://www.netpd.org/fl-hishv.png
>>>> Probably much closer to what you actually need is the [multiarray] from
>>>> the jmmmp library. It's in Deken.
>>>>
>>>> Roman
>>>>
>>>> _______________________________________________
>>>> Pd-list(a)lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>> _______________________________________________
>>> Pd-list mailing list
>>>
>>> Pd-list(a)lists.iem.at
>>>
>>> to manage your subscription (including un-subscription) see
>>>
>>> https://lists.puredata.info/listinfo/pd-list
>>
>> _______________________________________________
>> Pd-list(a)lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
Hi hans,
You should try my sarray abstraction (based on this discussion
https://forum.pdpatchrepo.info/topic/11184/colarray-a-graphical-array-where…)
download here https://github.com/jyg/mob/releases/tag/mob-0.1
There is some trickery to get an array name with $0 tag, but it's explained
J.Y.G.
> Re: [PD] is there a way to color the points/curve in an array?
> From:
> "hans w. koch" <hansw.koch(a)gmail.com>
> Date:
> 28/05/2021 Ã 22:02
>
> To:
> Pd-List <pd-list(a)lists.iem.at>
>
>
> thank you, roman and alexandre, for the pointers!
>
> it seems, the best option is to wait, till the discussion alexandre
> referenced (https://github.com/pure-data/pure-data/pull/711) comes to
> fruition.
> purr data has implemented such a color picker for arrays, so that
> would be the second best option.
> i looked into Jmmmp multiarray, but i seemed to be better suited at
> displaying static waveforms.
> maybe i overlooked something.
>
> i am (ab)using pd as an eight channel oszilloscope.
> things get messy pretty fast without colors.
>
>
>
>
>
>> Am 28.05.2021 um 14:59 schrieb Roman Haefeli <reduzent(a)gmail.com
>> <mailto:reduzent@gmail.com>>:
>>
>> On Fri, 2021-05-28 at 14:04 +0200, Roman Haefeli wrote:
>>> On Fri, 2021-05-28 at 13:31 +0200, hans w. koch wrote:
>>>> using 4 superimposed arrays to show different waveforms (e.g. phase
>>>> differences), i was wondering, if there is a way to assign a unique
>>>> color to each array, to visually better separate the waveforms.
>>>> i found a discussion "[PD] Array Enhancements" about that (and
>>>> other
>>>> things, like "Hide Array name” - still not working) from 2009 [1]
>>>> and
>>>> another one "[PD] colored arrays?” from 2007 [2],
>>>> but no tangible result - or i missed that, then sorry!
>>>
>>> As someone mentioned in one of the other threads, you could achieve
>>> colored array displays with data structures.
>>>
>>> An example is here:
>>> https://www.netpd.org/fl-hishv.png
>>
>> Probably much closer to what you actually need is the [multiarray] from
>> the jmmmp library. It's in Deken.
>>
>> Roman
>>
>> _______________________________________________
>> Pd-list(a)lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list mailing list
> Pd-list(a)lists.iem.at
> to manage your subscription (including un-subscription) see
> https://lists.puredata.info/listinfo/pd-list
using 4 superimposed arrays to show different waveforms (e.g. phase differences), i was wondering, if there is a way to assign a unique color to each array, to visually better separate the waveforms.
i found a discussion "[PD] Array Enhancements" about that (and other things, like "Hide Array name” - still not working) from 2009 [1] and another one "[PD] colored arrays?” from 2007 [2],
but no tangible result - or i missed that, then sorry!
if not, would that warrant a sensible feature request?
thanks
hans
[1]: https://lists.puredata.info/pipermail/pd-list/2009-09/072542.html
[2]: https://lists.puredata.info/pipermail/pd-list/2007-11/056251.html
(resending to the list, as i answered to jean-yves privatley only by mistake - sorry)
>
>
> thanks jean-yves,
>
> thats some serious wizzardry and it seems that i could build my oscilliscope from that :-)
> have to study it a bit more to really understand, whats going on under the hood.
>
> in the meantime i built sth with purr data, which has a properties dialogue with a colorpicker. for arrays.
> (i wanted sth simple + workable quickly).
> ultimately i think, that would be good to have in pd as well.
>
> also will check out your mob collection, as i am a big fan of mobmuplat, which sadly seems dormant but still keeps working on the newest iOS.
>
> best
> hans
>
>
>> Am 29.05.2021 um 10:17 schrieb Jean-Yves Gratius <jyg(a)gumo.fr>:
>>
>> Hi hans,
>>
>> You should try my sarray abstraction (based on this discussion https://forum.pdpatchrepo.info/topic/11184/colarray-a-graphical-array-where…)
>>
>> download here https://github.com/jyg/mob/releases/tag/mob-0.1
>>
>> There is some trickery to get an array name with $0 tag, but it's explained
>>
>> J.Y.G.
>>
>>> Re: [PD] is there a way to color the points/curve in an array?
>>> From: "hans w. koch" <hansw.koch(a)gmail.com>
>>> Date: 28/05/2021 à 22:02
>>> To: Pd-List <pd-list(a)lists.iem.at>
>>>
>>> thank you, roman and alexandre, for the pointers!
>>>
>>> it seems, the best option is to wait, till the discussion alexandre referenced (https://github.com/pure-data/pure-data/pull/711) comes to fruition.
>>> purr data has implemented such a color picker for arrays, so that would be the second best option.
>>> i looked into Jmmmp multiarray, but i seemed to be better suited at displaying static waveforms.
>>> maybe i overlooked something.
>>>
>>> i am (ab)using pd as an eight channel oszilloscope.
>>> things get messy pretty fast without colors.
>>>
>>>
>>>
>>> <oszi8.pd.jpg>
>>>
>>>
>>>> Am 28.05.2021 um 14:59 schrieb Roman Haefeli <reduzent(a)gmail.com>:
>>>>
>>>> On Fri, 2021-05-28 at 14:04 +0200, Roman Haefeli wrote:
>>>>> On Fri, 2021-05-28 at 13:31 +0200, hans w. koch wrote:
>>>>>> using 4 superimposed arrays to show different waveforms (e.g. phase
>>>>>> differences), i was wondering, if there is a way to assign a unique
>>>>>> color to each array, to visually better separate the waveforms.
>>>>>> i found a discussion "[PD] Array Enhancements" about that (and
>>>>>> other
>>>>>> things, like "Hide Array name” - still not working) from 2009 [1]
>>>>>> and
>>>>>> another one "[PD] colored arrays?” from 2007 [2],
>>>>>> but no tangible result - or i missed that, then sorry!
>>>>>
>>>>> As someone mentioned in one of the other threads, you could achieve
>>>>> colored array displays with data structures.
>>>>>
>>>>> An example is here:
>>>>> https://www.netpd.org/fl-hishv.png
>>>>
>>>> Probably much closer to what you actually need is the [multiarray] from
>>>> the jmmmp library. It's in Deken.
>>>>
>>>> Roman
>>>>
>>>> _______________________________________________
>>>> Pd-list(a)lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-list mailing list
>>>
>>> Pd-list(a)lists.iem.at
>>>
>>> to manage your subscription (including un-subscription) see
>>>
>>> https://lists.puredata.info/listinfo/pd-list
>>
>>
>> _______________________________________________
>> Pd-list(a)lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>