Re: [PD] Pd FLOSS Manual, what to do with it?

[Dan Wilcox]

My 2 cents...

> On May 31, 2021, at 11:07 PM, Alexandre Torres Porres  
> wrote:
> 
> what's a "pd-extended location" and where is it?
>  
> 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.
> 
> It has now come to my attention that we have different versions of this 
> manual. There's an archived version => 
> http://archive.flossmanuals.net/pure-data/ 
>  


This link is what I consider the "pd-extended" manual as it was written focused 
on extended, although naturally most of what's there works with vanilla. I 
would say keep this archived as it is but add some header text and make some 
edits so it is clear this is

1. for Pd-extended which is no longer maintained
2. kept for archival purposes
3. people should look to the "main" Pd-vanilla manual, where that will be

As to organization and where to put things and who does what, well it looks 
like mickfuzz is already started on it. In fact, who archived the old manual? 
Maybe he/she/they did...


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] Pd FLOSS Manual, what to do with it?

[Alexandre Torres Porres]

there's also yet another link here which seems to refer to the same content
of the new incarnation of the manual
http://write.flossmanuals.net/pure-data/introduction2/

why? dear god, why?

Em seg., 31 de mai. de 2021 às 18:07, Alexandre Torres Porres <
por...@gmail.com> escreveu:

> Em seg., 31 de mai. de 2021 às 07:35, Dan Wilcox 
> escreveu:
>
>> I agree. I think the current Pd-extended focused manual could be moved to
>> a Pd-extended location for historical reasons.
>>
>
> what's a "pd-extended location" and where is it?
>
>
>> 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.
>>
>
> It has now come to my attention that we have different versions of this
> manual. There's an archived version =>
> http://archive.flossmanuals.net/pure-data/
>
> And a new version created two months ago by 'mickfuzz' which is actually
> the same! https://en.flossmanuals.net/pure-data - The Pd Vanila html
> manual references to this link, by the way, and also to a french version
> here:  https://fr.flossmanuals.net/puredata/introduction/
>
> Note that the french version is considerably different, so yeah, we have
> quite some chaos... there are two versions somehow, different and
> independent unofficial takes on what a Pd manual is and should be and
> depending on what language you speak you get a different idea and
> information? :)
>
> Well, I'd love to help sort things out, but I don't know where to start,
> it's all decentralized in a very messy way.
>
> We need to coordinate the efforts if anything is to be done. I speak no
> french, for instance
>
> Where are the floss manuals people anyway? Who is 'mickfuzz'? Who's
> working on the french version?
>
> How could I get involved in the english one?
>
> Thanks
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd FLOSS Manual, what to do with it?

[Alexandre Torres Porres]

Em seg., 31 de mai. de 2021 às 07:35, Dan Wilcox 
escreveu:

> I agree. I think the current Pd-extended focused manual could be moved to
> a Pd-extended location for historical reasons.
>

what's a "pd-extended location" and where is it?


> 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.
>

It has now come to my attention that we have different versions of this
manual. There's an archived version =>
http://archive.flossmanuals.net/pure-data/

And a new version created two months ago by 'mickfuzz' which is actually
the same! https://en.flossmanuals.net/pure-data - The Pd Vanila html manual
references to this link, by the way, and also to a french version here:
https://fr.flossmanuals.net/puredata/introduction/

Note that the french version is considerably different, so yeah, we have
quite some chaos... there are two versions somehow, different and
independent unofficial takes on what a Pd manual is and should be and
depending on what language you speak you get a different idea and
information? :)

Well, I'd love to help sort things out, but I don't know where to start,
it's all decentralized in a very messy way.

We need to coordinate the efforts if anything is to be done. I speak no
french, for instance

Where are the floss manuals people anyway? Who is 'mickfuzz'? Who's working
on the french version?

How could I get involved in the english one?

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

Re: [PD] Pd FLOSS Manual, what to do with it?

[Andy Farnell]

The option I feel safest with is (3). Why do I mention safety? I'm not 
saying there is anything wrong with Flossmanuals - *really, but in the 
last few years, as my focus has shifted to cybersecurity and digital rights. 
I've become dismayed with governance issues in free software, from the 
Microsoft takeover of Github to last week's exodus from Freenode... it's 
genuinely a hostile landscape. Diversity obviously does make extra work, 
but it brings resilience. Having only one "official" document is nice but
 not necessary, so long as there's broad accord and a will to clean up 
outdated and misleading materials (one reason I nuked the old obiwannabe
Pd junk pile, the best of which had been ported into Flossmanuals. I found
the community was actually better at maintaining my patches than I was). 
Obviously documentation is not as important as the codebase itself, but 
still a significant asset to lose to a BigTech attack.

* As far as I can see the Dutch non-profit headed by Adam Hyde is exemplary, 
but unless an org literally has anti-takeover measures legally hard-coded 
into its articles of incorporation (or whatever that means under Nederlands 
non-profit law), there's a gap in the wall. 

Perhaps that falls under "other thoughts?", and sorry of it adds noise.

keep well all,
Andy


On Sun, May 30, 2021 at 05:19:35PM -0300, Alexandre Torres Porres wrote:
> 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 

Re: [PD] is there a way to color the points/curve in an array ?

[Dan Wilcox]

> On May 31, 2021, at 6:39 PM, pd-list-requ...@lists.iem.at wrote:
> 
> now i?ll be opening a new topic on how to create one in gem, as joao 
> suggested.
> i really have no clue, where to start?

[scopeXYZ~] ? ala https://github.com/jyg/gemscope- 
 etc... 


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] data structure flickering

[Miller Puckette via Pd-list]

This is a long-standing problem... I've been putting off optimizing this
until I can get my head around some improvements I want to make first.

cheers
Miller

On Thu, May 20, 2021 at 04:37:02PM +0200, Roman Haefeli wrote:
> 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



> ___
> 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] is there a way to color the points/curve in an array ?

[hans w. koch]

ok, i bulit a simple colored 8chan oscilloskope from the pdpatchrepo link given 
by jean-yves.
it fits my needs, though it suffers from some unpleasant flickering - i attach 
it anyway, in case someone finds it useful.
(its “oszi8_color.pd” in the folder. pretty self-explanatory, if you have an 
8ch audio interface, but less is of course possible too)

now i´ll be opening a new topic on how to create one in gem, as joao suggested.
i really have no clue, where to start…

thanks to everybody who contributed to the thread!

best
hans

<>


> Am 29.05.2021 um 12:06 schrieb Jean-Yves Gratius :
> 
> 
> 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-color-and-line-width-can-be-set)
> 
>  , 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 :
>>> 
>>> Hi hans,
>>> 
>>> You should try my sarray abstraction (based on this discussion 
>>> https://forum.pdpatchrepo.info/topic/11184/colarray-a-graphical-array-where-color-and-line-width-can-be-set)
>>> 
>>> 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" 
 Date: 28/05/2021 à 22:02
 To: Pd-List 
 
 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 :
> 
> 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@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
 
 
 ___
 Pd-list mailing list
 
 Pd-list@lists.iem.at
 
 to manage your subscription (including un-subscription) see
 
 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
> 
> 
> 
> 
> 
> ___
> 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] Pd FLOSS Manual, what to do with it?

[Dan Wilcox]

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-requ...@lists.iem.at wrote:
> 
> Message: 1
> Date: Sun, 30 May 2021 18:48:18 -0300
> From: Esteban Viveros mailto:emvive...@gmail.com>>
> To: Alexandre Torres Porres mailto:por...@gmail.com>>
> Cc: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] Pd FLOSS Manual, what to do with it?
> Message-ID:
>>
> 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 
danomatika.com 
robotcowboy.com 



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