Re: [PD] inlet names (bad?) practice?

[Jonathan Wilkes via Pd-list]

> On Tuesday, March 2, 2021, 2:48:36 PM EST, Alexandre Torres Porres 
>  wrote: 
 
 Em ter., 2 de mar. de 2021 às 16:26, Jonathan Wilkes  
escreveu:

Pd-l2ork 1.0 has tooltips

> hmm, but how does it work?
By fetching the data from `[pd META]` subpatches in help patches, which is the 
same across abstractions, binary externals, and internal classes.

> Does it show the symbol from an inlet argument?
Nope. I knew one *could* abuse inlet(~)/outlet(~) to write descriptions of the 
data flowing, but I didn't know until last week that anyone was actually using 
it to do that in practice.

I'd strongly advise investigating a way to implement tooltips that is more 
robust-- one that handles cases for externals as well as showing a general 
description when mousing over the main rectangle of an object.

Otherwise you'll end up with something like Cascading Style Sheets where the 
data for tips is scattered all over the place, or tooltip data in one place 
overrides tooltip data in another, etc.

-Jonathan

> If so, there is in fact a version of Pd that implements this.
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] inlet names (bad?) practice?

[Jonathan Wilkes via Pd-list]

> On Tuesday, March 2, 2021, 1:57:43 PM EST, Alexandre Torres Porres 
>  wrote: 
 > Thanks for the pointers, I don't see this implemented in Extended (42/43) or 
 > in Purr Data by extension. By readng the discussion, the patch was never 
 > included in the distribution, right?
AFAICT, the example code linked there has never been included in any 
implementation.
Pd-l2ork 1.0 has tooltips, but they don't use any of the code in that link.
-Jonathan

> So it was more like a plan than a reality?
Em ter., 2 de mar. de 2021 às 15:20, Claude Heiland-Allen  
escreveu:

On 02/03/2021 17:45, Jonathan Wilkes via Pd-list wrote:
> > On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres 
>  wrote:
>
> > Hi, I was asking people on facebook where did they get the idea of 
> putting names in inlets/outlets, like: [inlet 
> this-inlet-controls-frequency].
>
> Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that 
> allows an arbitrary number of extra float/symbol arguments, so it 
> could be `[inlet this inlet controls frequency]`. Or following the 
> `[get]` and `[set]` pattern-- `[inlet - this inlet controls 
> frequency]` to skip over the first arg that is currently used for 
> up/downsampling.
>
> Someone asked on the Purr Data list about this. It would be easy to 
> implement, but it doesn't cover the case of setting a description for 
> the object itself. Plus I'd much rather just leverage the 
> documentation index in the GUI to look up tooltip data.
>
> -Jonathan
https://download.puredata.info/dev/InletDescriptions




___
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] inlet names (bad?) practice?

[Jonathan Wilkes via Pd-list]

> On Tuesday, March 2, 2021, 2:11:36 PM EST, Alexandre Torres Porres 
>  wrote: 
 > The idea doesn't sound bad, it'd be a nice GUI feature. As for the design, I 
 > think you'd need a special flag to set the name and not just some symbol, 
 > this way you'd not get into conflicts with the actual arguments.
I have no plans to implement it that way, and the tooltip implementation we 
wrote in 
Pd-l2ork 1.0 draws directly from the help patches for its tooltip data.
However, if it turns out that a sizable number of users are abusing 
inlet(~)/outlet(~) args that way and they really want it displayed in the 
tooltip, I'll revisit it.
-Jonathan

> Well, anyway, someone started abusing the fact that the object doesn't 
> complain about invalid arguments and now I can only see this as a bad 
> practice indeed. I like to joke that Pd will not complain if you create [osc~ 
> 440 hz (cycles per second)], but that doesn't mean you should do it :) 
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] inlet names (bad?) practice?

[Jonathan Wilkes via Pd-list]

> On Tuesday, March 2, 2021, 1:19:53 PM EST, Claude Heiland-Allen 
>  wrote: 
 > On 02/03/2021 17:45, Jonathan Wilkes via Pd-list wrote:
> > On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres 
>  wrote:
>
> > Hi, I was asking people on facebook where did they get the idea of 
> putting names in inlets/outlets, like: [inlet 
> this-inlet-controls-frequency].
>
> Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that 
> allows an arbitrary number of extra float/symbol arguments, so it 
> could be `[inlet this inlet controls frequency]`. Or following the 
> `[get]` and `[set]` pattern-- `[inlet - this inlet controls 
> frequency]` to skip over the first arg that is currently used for 
> up/downsampling.
>
> Someone asked on the Purr Data list about this. It would be easy to 
> implement, but it doesn't cover the case of setting a description for 
> the object itself. Plus I'd much rather just leverage the 
> documentation index in the GUI to look up tooltip data.
>
> -Jonathan
> https://download.puredata.info/dev/InletDescriptions
Yeah, perhaps they got it by somehow discovering that ancient scroll. :)

Anyhow, Albert Graef recently made a nice caching system for the Purr Data doc 
index. Leveraging that, I *think* I can now add tooltips, completely in the GUI 
of Purr Data, and only require a single extra string to be sent from the 
backend on object creation. At that point tooltips would be the cost of 
essentially looking up a key in JSON, and the cost of the additional DOM 
element to display it on hover (which would be zero if tooltips are disabled).
-Jonathan
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] inlet names (bad?) practice?

[Jonathan Wilkes via Pd-list]

> On Tuesday, March 2, 2021, 11:10:36 AM EST, Alexandre Torres Porres 
>  wrote:  
 > Hi, I was asking people on facebook where did they get the idea of putting 
 > names in inlets/outlets, like: [inlet this-inlet-controls-frequency].
Not sure. But A_DEFSYM and A_DEFFLOAT are implemented in a way that allows an 
arbitrary number of extra float/symbol arguments, so it could be `[inlet this 
inlet controls frequency]`. Or following the `[get]` and `[set]` pattern-- 
`[inlet - this inlet controls frequency]` to skip over the first arg that is 
currently used for up/downsampling.

Someone asked on the Purr Data list about this. It would be easy to implement, 
but it doesn't cover the case of setting a description for the object itself. 
Plus I'd much rather just leverage the documentation index in the GUI to look 
up tooltip data.

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

Re: [PD] list item picker widget

[Jonathan Wilkes via Pd-list]

It's possible to build one with data structures. There may be one from me or 
others on the pd forum. But it's really a pain to build.
In Purr Data I just made a core object "dropdown" built on the same simple 
display that an atom box has.

Best,Jonathan

On Thursday, February 11, 2021, 7:46:02 AM EST, Roman Haefeli 
 wrote:  
 
 Hi

I'm curious what types of list item pickers widgets exist in Pd realm.
I imagine a widget that lets you select an item from a arbitrary length
list that only displays the picked item and thus uses little screen
estate when not in active use.

I don't know any but the kludgy ones I made myself. I'd be specially
interested in patched ones as opposed to externals, though externals
would be interesting to know about, too. Maybe there is something made
of data structures?


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] [OT]Re: Preset management for Pd Vanilla

[Jonathan Wilkes via Pd-list]

 > On Thursday, January 21, 2021, 10:14:19 PM EST, Miller Puckette 
 >  wrote: 
 > that's right - savestate just lets a patch add stuff to its parent
(calling) patch when the parent is saved, that is retrieved when reloaded
from a file.  I don't know of other meanings of "savestate" although the
name does (unfortunately) suggest that it's for object archiving ala
NeXTStep (and I think earlier from Smalltalk).

At first glance "savestate" seemed like it might be related to "state saving," 
e.g., a core class that provides the hooks necessary to take a "snapshots" at 
will of system state without requiring the user to prepare the patch for that 
purpose ahead of time.

cheers
M

On Fri, Jan 22, 2021 at 03:05:02AM +, Jonathan Wilkes via Pd-list wrote:
>    > On Thursday, January 21, 2021, 6:35:34 PM EST, cyrille henry 
> wrote:  
>  > here we are :
> https://urldefense.com/v3/__https://xkcd.com/927/__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-OTEv7cY$
>  
> 
> This case seems more like the Lisp problem-- every single user has their own 
> non-standard, incompatible, and deeply personal solution to the problem.
> Also-- do I have it right that the only relevant native core class 
> "savestate" isn't about statesaving in its common parlance, but is instead a 
> callback hard-coded to the "save" event that writes a patch file to the 
> filesystem? That's what the guts looked like when I ported it to Purr Data, 
> but I haven't really used it yet.
> 
> -Jonathan
> 
> Le 21/01/2021 ?? 20:48, Antoine Rousseau a ??crit??:
> > You can also have a look to my "AutoPreset" system. It's available from 
> > deken. It's rather old, but that's what I use every day...
> > 
> > Le jeu. 21 janv. 2021 ?? 19:39, Alexandre Torres Porres  > <mailto:por...@gmail.com>> a ??crit??:
> > 
> >?? ?? Em qui., 21 de jan. de 2021 ??s 15:09, Alexandre Torres Porres 
> >mailto:por...@gmail.com>> escreveu:
> > 
> >?? ?? ?? ?? I??now included "import" and "export" functions so [savestate] 
> >can be used in conjunction
> > 
> > 
> >?? ?? Just making clear this design allows each instance to be saved with 
> >separate presets in a parent patch. Not that I find it crucial. I guess that 
> >2 sharing the same preset bank should be fine for most cases. So using a 
> >file to load and save inside the abstraction (as it was possible before) was 
> >kinda fine. So this is where I start to think I could be compromising my 
> >beloved "KISS" principle... but I was already thinking??import/export was 
> >nice to allow people to store these things in the patch rather than a file, 
> >so it's cool. It's versatile and still simple enough.
> > 
> >?? ?? ___
> >?? ?? Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
> >?? ?? UNSUBSCRIBE and account-management -> 
> >https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
> > 
> > 
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
> >  
> > 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
>  
>  

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!R6uAxiWLBX_uU5Ci0LdXHpjrQ9nqMwFrdbZWOnVFuZoBOC0XTicG-JUVfeeD$
>  

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

Re: [PD] [OT]Re: Preset management for Pd Vanilla

[Jonathan Wilkes via Pd-list]

   > On Thursday, January 21, 2021, 6:35:34 PM EST, cyrille henry 
 wrote:  
 > here we are :
https://xkcd.com/927/

This case seems more like the Lisp problem-- every single user has their own 
non-standard, incompatible, and deeply personal solution to the problem.
Also-- do I have it right that the only relevant native core class "savestate" 
isn't about statesaving in its common parlance, but is instead a callback 
hard-coded to the "save" event that writes a patch file to the filesystem? 
That's what the guts looked like when I ported it to Purr Data, but I haven't 
really used it yet.

-Jonathan

Le 21/01/2021 à 20:48, Antoine Rousseau a écrit :
> You can also have a look to my "AutoPreset" system. It's available from 
> deken. It's rather old, but that's what I use every day...
> 
> Le jeu. 21 janv. 2021 à 19:39, Alexandre Torres Porres  > a écrit :
> 
>    Em qui., 21 de jan. de 2021 às 15:09, Alexandre Torres Porres 
>mailto:por...@gmail.com>> escreveu:
> 
>        I now included "import" and "export" functions so [savestate] can be 
>used in conjunction
> 
> 
>    Just making clear this design allows each instance to be saved with 
>separate presets in a parent patch. Not that I find it crucial. I guess that 2 
>sharing the same preset bank should be fine for most cases. So using a file to 
>load and save inside the abstraction (as it was possible before) was kinda 
>fine. So this is where I start to think I could be compromising my beloved 
>"KISS" principle... but I was already thinking import/export was nice to allow 
>people to store these things in the patch rather than a file, so it's cool. 
>It's versatile and still simple enough.
> 
>    ___
>    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
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Jonathan Wilkes via Pd-list]

Em qui., 21 de jan. de 2021 às 14:33, Alexandre Torres Porres 
 escreveu:

> hmm, here's something I wasn't thinking, how to allow one to use the system 
> inside abstractions.
IIRC, the symbolic name given as an argument to preset_hub sets the scope for 
all the preset_node objects with the same name in that canvas (or inside any 
child abstractions, so long as they don't include their own preset_hub inside 
with the same name). So basically the same way 'var' sets scope in Javascript. 
That's why "$0" isn't needed.
Digression-- there's also a new [ab] class in Purr Data which saves 
abstractions with the parent file, and it uses a "canvas private" scoping 
mechanism so that "$0" isn't needed. (Although in that case, file-level 
abstractions are in their own scope for the sake of sanity.)
I find it really handy and would like to find a way to make struct names 
similarly scoped. (Perhaps with a flag.)
-Jonathan


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

Re: [PD] fluid~

[Jonathan Wilkes via Pd-list]

> On Friday, December 11, 2020, 6:21:03 PM EST, Alexandre Torres Porres 
>  wrote:  
> Hi, anyone has had any luck in building the old fluid~ external out there?
> seems the original repository is here 
> https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fluid/fluid/main.cpp
> It seems this is available in Purr Data and I was hoping maybe we could have 
> a new repository on github or something and release a new version for Pd 
> Vanilla so it's available via deken.
I'd strongly suggest using the source from Purr Data:
https://git.purrdata.net/jwilkes/purr-data/-/tree/master/externals/fluid~
It's a simple C external, unlike the footils version which depends on flext. 
It's also had some bugfixes and new features that Albert Graef recently added.
Best,Jonathan


cheers___
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] Purr-Data running in the browser

[Jonathan Wilkes via Pd-list]

Hi Christof,
Thanks for reposting about this. It was a gargantuan undertaking, and I am 
still amazed at what Zack and Hugo were able to achieve over the summer.
Zack has a nice set of build instructions that seem to be working pretty well. 
The next step is hooking that in to the gitlab CI system so we can upload a 
publicly available rolling version.

If anyone wants to hack on it, shoot me an email.
Best,Jonathan


   On Wednesday, November 4, 2020, 4:14:40 AM EST, Christof Ressi 
 wrote:  
 
   
Hi,
 
I'm reposting the following FB post by Ico Bukvic because I think it is very 
exciting:
 
 

  Revolution in the making...   An alpha version of a fully embedded 
Pd-L2Ork 2.x, a.k.a. Purr-Data running inside the Chrome web browser, including 
the support for third-party externals (to the extent that the current browser 
supports, e.g. 3D Gem objects are not yet supported).   Special thanks to the 
Google Summer of Code participants Zack Lee, Hugo Carvalo, and Guillem Bartrina 
Moreno for some truly fantastic work! Stay tuned for more exciting updates 
soon!L2Ork: Virginia Tech Linux Laptop Orchestra  #pdl2ork  
 
Article on CDM: 
https://cdm.link/2020/10/pure-data-is-running-in-the-browser-for-free-web-based-sound-patching/?fbclid=IwAR37aB_T5C6tTifCHnq7W9ToOEYUqeT1XXEE6VtGDP6vrbvETdixgO52wEQ
 
 
Demo: 
https://www.youtube.com/watch?v=DVU-tz8Wxl4=youtu.be=IwAR2wkOKJMzJ3gMKSkdUDv-c50XlaonXufmEmlG-vJ6KaNBNkL4Jna_vOlEg
 
About Purr-Data: https://agraef.github.io/purr-data/
 
 
About L2Ork: http://l2ork.icat.vt.edu/main/
 
---
 
Note that Claude Heiland-Allen has already been working on compiling libpd 
(without GUI) to WASM via Emscripten https://mathr.co.uk/empd/
 
 
---
 
Christof
 
 

 
 ___
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] Inlet - Unexpected Behaviour

[Jonathan Wilkes via Pd-list]

> I agree that it's not practical for you to submit patches both to Pd vanilla 
> and PurrData. After all, it is mostly trivial to backport the changes. Just 
> let us know occasionally when you've found some critical issues :-)
Will do.
Best,Jonathan
 
> Christof
 
 On 29.08.2020 21:58, Jonathan Wilkes via Pd-list wrote:
  
 
 
  
  On Saturday, August 29, 2020, 03:04:25 PM EDT, Alexandre Torres Porres 
 wrote:  
  
  Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes  
escreveu:
 
> On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi 
 wrote:   
   > Dear people
  
  > In my role as village idiot, I am asking whether the string "fwd" in a 
message has a
  special meaning to inlet.
  
  > Naively, I was expecting inlet to pass the string to the subpatch, but it 
seems not
  to. See example patch attached.
  
  AFAICT that's a regression due to the way Pd Vanilla implemented message 
forwarding for 
   [inlet~ fwd]. That's a feature that allows a signal inlet of a 
subpatch/abstraction to forward 
  non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet 
sprouts when the 
  "fwd" argument is present.) 
  Another regression-- there is no longer an error if you try to send a 
non-signal message to 
  [inlet~]. 
  Another regression-- [inlet~ fwd] unconditionally allocates space on the 
stack to copy the 
  entire incoming message. If you generate a long enough message this will blow 
the stack 
  and cause Pd to crash. Esp. important given that Windows stack is much 
smaller than the RAM 
  available for heap allocation on most machines. 
  Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ 
fwd]. It appeared to be an oversight-- at least I didn't see any comment about 
it.
  
  A GSoC student spent some time reimplementing this in Purr Data, so none of 
thiese should be 
  issues there.  
  
  
  > I think it's a good idea if you're changing and fixing stuff to also send a 
PR to vanilla as a proposal. Would you consider doing that as well? 
  Before you ask that, have a look at the PRs. You can view the list of open 
PRs for Pure Data Vanilla here: 
  https://github.com/pure-data/pure-data/pulls
  
  It appears Christof (Spacechild1) submitted a patch for this almost a month 
ago. So it wouldn't make sense to send another 
  PR for this same fix. Christof's patch should work just fine to solve these 
issues. 
  If you're asking in general, that's unfortunately just not practical. We'd 
have to manually create a new patch set and test it  for Vanilla, for (nearly) 
every single change we make. It's much easier to just report here when I find 
crashers-- Miller and Christof  are quite quick to fix them. They know the 
Vanilla build/test/development process much better than I do so that seems the 
much preferable route for everyone involved. 
  Best, Jonathan   
  ___
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] Inlet - Unexpected Behaviour

[Jonathan Wilkes via Pd-list]

 

On Saturday, August 29, 2020, 03:04:25 PM EDT, Alexandre Torres Porres 
 wrote:  
 
 Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes  
escreveu:

 > On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi 
 >  wrote: 
 > Dear people

> In my role as village idiot, I am asking whether the string "fwd" in a 
> message has a
special meaning to inlet.

> Naively, I was expecting inlet to pass the string to the subpatch, but it 
> seems not
to. See example patch attached.

AFAICT that's a regression due to the way Pd Vanilla implemented message 
forwarding for 
 [inlet~ fwd]. That's a feature that allows a signal inlet of a 
subpatch/abstraction to forward 
non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet 
sprouts when the 
"fwd" argument is present.)
Another regression-- there is no longer an error if you try to send a 
non-signal message to 
[inlet~].
Another regression-- [inlet~ fwd] unconditionally allocates space on the stack 
to copy the 
entire incoming message. If you generate a long enough message this will blow 
the stack 
and cause Pd to crash. Esp. important given that Windows stack is much smaller 
than the RAM 
available for heap allocation on most machines.
Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ 
fwd]. It appeared to be an oversight-- at least I didn't see any comment about 
it.

A GSoC student spent some time reimplementing this in Purr Data, so none of 
thiese should be 
issues there.


> I think it's a good idea if you're changing and fixing stuff to also send a 
> PR to vanilla as a proposal. Would you consider doing that as well?
Before you ask that, have a look at the PRs. You can view the list of open PRs 
for Pure Data Vanilla here:
https://github.com/pure-data/pure-data/pulls

It appears Christof (Spacechild1) submitted a patch for this almost a month 
ago. So it wouldn't make sense to send another 
PR for this same fix. Christof's patch should work just fine to solve these 
issues.
If you're asking in general, that's unfortunately just not practical. We'd have 
to manually create a new patch set and test it for Vanilla, for (nearly) every 
single change we make. It's much easier to just report here when I find 
crashers-- Miller and Christof are quite quick to fix them. They know the 
Vanilla build/test/development process much better than I do so that seems the 
much preferable route for everyone involved.
Best,Jonathan  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] inlet: expected 'signal' but got 'bang'

[Jonathan Wilkes via Pd-list]

 

> On Thursday, July 16, 2020, 6:58:40 PM EDT, Sebastian Lexer 
 wrote:  
 
 > Hi,

> Getting desperate after spending hours to locate the error "inlet: expected 
> 'signal' but got ‘bang’” I am getting from a fairly huge project, running in 
> pd 0.49 on a raspberry pi.

> The only object I am aware of being able to produce an error like this is the 
> [inlet~]. After checking all subpatches I have not found any [inlet~] that 
> has any non-signal patch cords connected.

> Is anyone here aware of any other objects that might produce the above error 
> message? The 'last error' feature does unfortunately not give a result or 
> clue.
"inlet" is actually a bit of an implementation detail here. "inlet" is it's own 
little class that handles messages on behalf of ancillary 
inlets of a given object. The error should probably say "inlet of x" where x is 
the class name for the object that owns the inlet.

At least in Purr Data[1], each error has a hyperlink which will focus the 
appropriate canvas with the relevant object highlighted. So 
the vague error message is less problematic (though I just added an issue for 
it anyway[2])

It's not discoverable in Pd Vanilla, but you should be able to do the same 
thing like this:
1. click  (or maybe it's , I can't remember. The correct one will 
get you a weird-looking cursor)2. now armed with your weird-looking cursor, 
click on that vague error message
3. the object which caused the error should now be highlighted
Best,
Jonathan


1. https://agraef.github.io/purr-data-intro/Purr-Data-Intro.html
2. https://git.purrdata.net/jwilkes/purr-data/-/issues/661

> Thanks,
> Sebastian ___
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] adc/dac~ 'set' method on PD and purr data

[Jonathan Wilkes via Pd-list]

> On Tuesday, July 7, 2020, 5:48:58 PM EDT, Raphael Raccuia 
>  wrote: 
 
   > Hi!
 > since which version of PD the [set( method is implemented for [adc~] and 
 > [dac~] ?
 > I'm writing a patch for somedody using purr-data (2.11), but it's not 
 > working:

It's not in the Vanilla changelog, but I just added it to Purr Data and updated 
the docs after reading your message here.
We should be releasing a new version of Purr Data in the next few days so I'll 
merge this in.
Thanks,Jonathan


 error: adc~: no method for 'set'  thank you!

rph
 
 ___
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] getting vanilla gui objects into standalone builds

[Jonathan Wilkes via Pd-list]

> On Sunday, June 28, 2020, 11:13:31 AM EDT, hans w. koch 
>  wrote: 
 
 > well, as a relative oldie, let me tell you this is wrong :-)
> last commit to github 5 days ago: https://git.purrdata.net/jwilkes/purr-data
> last relase: 26 days ago (14 committs since): 
> https://github.com/agraef/purr-data/releases

> or your world is aging fatser than mine…

Also notice Ico has a huge number of merge requests from the past few weeks. 
That-- along withthe GSoC project merges to run Purr Data fully in a browser 
and the features to automatically 
"subpatchify" a selection-- has made the CI a real choke point.
If anyone has experience with making a monstrously complex recursive makefile 
system work 
with the -j flag, please shoot me an email.
Best,Jonathan

> hth
> hans

> Am 28.06.2020 um 16:28 schrieb henry birdseye :
> 
> As a relative newbie to PD, let me suggest that PurrData is old, and 
> incomplete. Unless you have a very specific reason for using it, PD Vanilla 
> is the one to use. 
> 
> On 6/28/2020 9:42 AM, Jakob Laue wrote:
>> Hi!
>> Alright, so I have looked a little bit into pdparty and mobmuplat. Seriously 
>> these are cool projects!
>> But I would like to have standalone apps, so it seems that I cannot use both 
>> of them..
>> Maybe I need to go for ofelia then or try native coding.
>>  
>> But it is also interesting what you mentioned about purr-data. I have heard 
>> of it a lot, but i dont know what it is. You mentioned that purr-data is 
>> able to port the native guis to non-tk-frameworks. Does this mean e.g. 
>> porting to iOS? I guess I need to take a look into purr-data as well:)
>>  
>> All the best, jakob
>>  
>>  
>> Gesendet: Sonntag, 21. Juni 2020 um 20:15 Uhr
>> Von: "Dan Wilcox" 
>> An: "Jakob Laue" 
>> Cc: "Pd-List" , "Christof Ressi" 
>> , "enrike" 
>> Betreff: Re: [PD] getting vanilla gui objects into standalone builds
>> Howdy Jakob,
>>  
>> There is no "standalone GUI" for mobile. The UI widgets for PdDroidParty and 
>> my own PdParty are custom re-implementations which intercept messages using 
>> sends/receives. Both apps are open source, so you can reuse the widgets but 
>> PdDroidParty's implementation is not feature complete, ie. no radio buttons, 
>> etc. MobMuPlat, for instance, uses the Pd UI implementation form PdParty.
>>  
>> For mobile, it's often better to use the native sliders and buttons and send 
>> the state changes to/from libpd. Either way, you will have to do native 
>> platform coding & integration, unless you simply want to run patches, in 
>> which case try using PdParty and/or PdDroidParty.
>>  
>> My long-term plan is to bring changes into libpd & the pd core so GUI 
>> messaging could be abstracted to make porting the native UIs to non-Tk 
>> frameworks easier. Purr-data has achieved this, for instance, so we know 
>> it's possible.
>>  
>> On Jun 21, 2020, at 1:52 PM, Christof Ressi  wrote:
>>  
>> Hi,
>> 
>> on desktop it's easy: just bundle Pd with your patch, add a simple starter 
>> script and maybe use the KIOSK plugin to hide the console.
>> 
>> Mobile is tricky, because of the locked down nature of the platforms 
>> (especially iOS). There are projects to run Pd patches on Android 
>> (http://droidparty.net/) and iOS (http://danomatika.com/code/pdparty) with 
>> some compatibility between the two 
>> (http://danomatika.com/code/pdparty/guide#pddroid-party-compatibility). You 
>> have to follow some conventions, though.
>> 
>> If you design your patch for PdParty and/or PdDroidParty and don't use 
>> mobile specific features, it should automatically work in desktop Pd 
>> vanilla. I think @Dan can tell you more about it.
>> 
>> Christof
>> 
>> On 21.06.2020 12:16, Jakob Laue wrote:
>> Hey dear friends,
>> i am currently building an instrument with many vanilla-native gui objects 
>> (mainly buttons).
>> I would like to build standalone versions of that patch, preferably for 
>> linux, osx, ios and android.
>> I know that building standalones is possible eg with ofxPof or ofelia. But 
>> as far as i know, if i use ofxPof or ofelia, I will need to use "their" gui 
>> objects, which means re-working my patch.
>>  
>> Do you know of a tool that allows building standalone versions from a pd 
>> patch that will keep the original pd-vanilla-gui objects - or even better - 
>> a tool that is able to "convert" pd-vanilla-gui objects into its own types 
>> of gui objects, which look maybe a bit different from the pd-object, but 
>> fulfill the same purpose?
>>  
>> :-)))
>>  
>> Best, jakob
>>    
>> ___
>> 
>> Pd-list@lists.iem.at
>>  mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>>  
>> 
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
>>  
>> 
>> 
>> ___
>> 
>> Pd-list@lists.iem.at
>>  mailing list
>> UNSUBSCRIBE and account-management -> 
>> 

Re: [PD] pd_defaultbang to non-default list handler

[Jonathan Wilkes via Pd-list]

 > On Sunday, June 21, 2020, 12:13:19 PM EDT, Miller Puckette via Pd-list 
 >  wrote:

> As far as I know, there's no design necessity that says it has to be zero.
The selector in this case is unspecified. One could invent one ("foo"
would be fine) or leave it at zero.

> Perhaps objects should not depend on knowing a selector that might be
undefined.

Thanks, Miller.

-Jonathan

> cheers
> Miller

On Sun, Jun 21, 2020 at 12:55:47AM +0200, Christof Ressi wrote:
> > I guess what I'm trying to ask is if there's a design constraint that
> > requires the selector to be null in said code. Or
> > better yet-- if the code were changed so that the selector is *never*
> > null would bad things happen?
> The selector is not *required* to selector to be NULL, but it *can* be NULL,
> with the only merit that it saves you a few characters.
>
> > if the code were changed so that the selector is *never* null would bad
> > things happen?
> In the above mentioned discussion, IOhannes has offered two patches: 1)
> don't use NULL selectors internally, 2) gracefully handle NULL selectors
> (e.g. coming from externals)
>
> Those patches obviously haven't been merged, but I think they should be
> reconsidered.
>
> Christof
>
>
> On 21.06.2020 00:47, Jonathan Wilkes wrote:
> > > On Saturday, June 20, 2020, 6:34:02 PM EDT, Christof Ressi
> >  wrote:
> >
> > > In pd_defaultbang, what is the reasoning for calling the list method
> > > with a null selector while calling the
> > > anything method with an "_bang" selector?
> > > contrary to the list method, the selector for the anything method
> > *does* carry significant meaning. At the very least, it's necessary for
> > the default anything method (which prints an error message).
> >
> > I guess what I'm trying to ask is if there's a design constraint that
> > requires the selector to be null in said code. Or
> > better yet-- if the code were changed so that the selector is *never*
> > null would bad things happen?
> >
> > Thanks,
> > Jonathan
> >
> > Christof
> >
> > On 21.06.2020 00:29, Christof Ressi wrote:
> >
> > Ah, sorry, I misread you're last reply. I thought you were repeating
> > your first question :-)
> >
> > On 21.06.2020 00:24, Christof Ressi wrote:
> >
> > Did you read the discussion I've linked too? To quote Miller:
> >
> > > I'm not sure this is a real problem - _anything and _list methods
> > > simply aren't guaranteed
> > > anything about the "s" argument - it shouldn't ever be dereferenced.
> >
> > I think this is the answer to your question. Since the selector of a
> > list message is actually redundant, you're free to pass NULL.
> >
> > Christof
> >
> > On 21.06.2020 00:16, Jonathan Wilkes wrote:
> > > On Saturday, June 20, 2020, 4:02:44 PM EDT, Christof Ressi
> >  <mailto:i...@christofressi.com> wrote:
> >
> >
> > > Hi, the selector for a list method certainly shouldn't be "bang",
> > rather it should be "list".
> >
> > Let's back up.
> >
> > Miller,
> >
> > In pd_defaultbang, what is the reasoning for calling the list method
> > with a null selector while calling the
> > anything method with an "_bang" selector?
> >
> > Thanks,
> > Jonathan
> >
> > > There has been a discussion about this in the past and I have agree
> > with IOhannes that Pd shouldn't send NULL selectors: 
> > https://urldefense.com/v3/__https://sourceforge.net/p/pure-data/patches/555/__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBR6LaLUw$
> > .
> >
> > > Christof
> >
> > On 20.06.2020 21:19, Jonathan Wilkes via Pd-list wrote:
> > Hi Miller,
> >
> > In pd_defaultbang of m_class.c, why does the list method get called with
> > "0" for a selector instead of "_bang" for the c_listmethod invocation?
> >
> > Best,
> > Jonathan
> >
> > ___
> > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
> > UNSUBSCRIBE and account-management 
> > ->https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!QsXvdm7PGfv5RyslUUuP4q13RXWyW2YlDB0Amsou_ol-eFRc-JQZBcArg5HE$
> > ___
> > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://urldefense.com/v3/__https://lists.puredata.inf

Re: [PD] pd_defaultbang to non-default list handler

[Jonathan Wilkes via Pd-list]

   > On Saturday, June 20, 2020, 6:34:02 PM EDT, Christof Ressi 
 wrote:  
  
 

 In pd_defaultbang, what is the reasoning for calling the list method with a 
null selector while calling the 
  anything method with an "_bang" selector? 
 > contrary to the list method, the selector for the anything method *does* 
 > carry significant meaning. At the very least, it's necessary for the default 
 > anything method (which prints an error message). 

I guess what I'm trying to ask is if there's a design constraint that requires 
the selector to be null in said code. Or 
better yet-- if the code were changed so that the selector is *never* null 
would bad things happen?

Thanks,
Jonathan

Christof
 
 On 21.06.2020 00:29, Christof Ressi wrote:
  
 

Ah, sorry, I misread you're last reply. I thought you were repeating your first 
question :-)
 
 On 21.06.2020 00:24, Christof Ressi wrote:
  
 

Did you read the discussion I've linked too? To quote Miller:
 
 
 
I'm not sure this is a real problem - _anything and _list methods simply aren't 
guaranteed
 anything about the "s" argument - it shouldn't ever be dereferenced.
 
I think this is the answer to your question. Since the selector of a list 
message is actually redundant, you're free to pass NULL.
 
 
Christof
 
 On 21.06.2020 00:16, Jonathan Wilkes wrote:
  
 
> On Saturday, June 20, 2020, 4:02:44 PM EDT, Christof Ressi 
 wrote:  
  
 > Hi, the selector for a list method certainly shouldn't be "bang", rather 
it should be "list". 
  
  Let's back up. 
  Miller, 
  In pd_defaultbang, what is the reasoning for calling the list method with a 
null selector while calling the 
  anything method with an "_bang" selector? 
  Thanks, Jonathan
  
> There has been a discussion about this in the past and I have agree with 
> IOhannes that Pd shouldn't send NULL selectors: 
> https://sourceforge.net/p/pure-data/patches/555/.
 
 
> Christof
 
  On 20.06.2020 21:19, Jonathan Wilkes via Pd-list wrote:
  
 
  Hi Miller, 
  In pd_defaultbang of m_class.c, why does the list method get called with "0" 
for a selector instead of "_bang" for the c_listmethod invocation? 
  Best, Jonathan
   
  ___
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
 
  ___
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_defaultbang to non-default list handler

[Jonathan Wilkes via Pd-list]

   > On Saturday, June 20, 2020, 4:02:44 PM EDT, Christof Ressi 
 wrote:  
 
 > Hi, the selector for a list method certainly shouldn't be "bang", rather it 
 > should be "list". 

Let's back up.
Miller,
In pd_defaultbang, what is the reasoning for calling the list method with a 
null selector while calling the 
anything method with an "_bang" selector?
Thanks,Jonathan

> There has been a discussion about this in the past and I have agree with 
> IOhannes that Pd shouldn't send NULL selectors: 
> https://sourceforge.net/p/pure-data/patches/555/.
 
 
> Christof
 
 On 20.06.2020 21:19, Jonathan Wilkes via Pd-list wrote:
  
 
 Hi Miller, 
  In pd_defaultbang of m_class.c, why does the list method get called with "0" 
for a selector instead of "_bang" for the c_listmethod invocation? 
  Best, Jonathan
   
  ___
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

[PD] pd_defaultbang to non-default list handler

[Jonathan Wilkes via Pd-list]

Hi Miller,
In pd_defaultbang of m_class.c, why does the list method get called with "0" 
for a selector instead of "_bang" for the c_listmethod invocation?
Best,Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] GOP drawing bug with scalars and z-order - test in [jmmmp/multiarray]

[Jonathan Wilkes via Pd-list]

> On Friday, September 20, 2019, 7:52:07 AM EDT, Christof Ressi 
>  wrote:  
 
 >> Pd doesn't care about z-ordering at all and the order of drawing is 
>> mainly defined by "what needs to be done" (rather than: "how will it 
>> look like").

> I don't agree that there is no defined z-ordering in Pd, otherwise you 
> couldn't reliably build GUIs.
Scalars in Pd Vanilla don't have a well-defined z-order:
1. Display a scalar square on top of a scalar circle2. Delete the scalar 
circle3. Undo the delete
Now the scalar circle is displayed on top of the scalar square.
Pure Data ought to retain the z-ordering in this and other circumstances. If it 
doesn't please submit a bug and I'll fix it.
Best,Jonathan
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-dev] what's the maximum list size?

[Jonathan Wilkes via Pd-list]

 > On Thursday, July 4, 2019, 07:52:05 PM EDT, Christof Ressi 
 >  wrote:
 
 >>  > how big of a list xcan we have in Pd?
>> 100

> That's only the internal limit for stack allocation in the [list] methods.

There's no easy way to measure the worst case performance for malloc/free, much 
less predict the worst cases on other supported platforms of Pd.
So if low latency realtime scheduling is desired, then the most sane way to 
achieve that is to limit the number of malloc/free calls to as few as possible 
during DSP computation (or if it's not a DSP-based patch, then during the 
normal runtime of the patch after all loadbangs have been fired).
That means always taking the stack allocation path for list classes. The way to 
do  that is to limit list output sizes to a maximum of 100 elements.
Also notice that any copying of lists requires a loop to copy each element of 
the list to the new list (regardless of how the target list got allocated). So 
for maximally  predictable runtime performance, try not to use any list objects 
that require copying lists. (This is why the crazy recursive list-abs/list-drip 
abstraction is performant.)
>> > How many elements can a t_atom have?
>> 1000

> What does this even mean?

It means evaluating a Pd message with greater than 1000 elements in a row which 
are neither commas or semis will trigger a malloc/free pair each time the 
message gets evaluated. So for low latency realtime performance scheduling, 
don't do that during normal patch runtime.
>> For best results, no bigger than:
>> 5

> Everything below 100 elements is equally fine (no heap allocation)

Five elems and below avoids an alloca call by just assigning to a 5 element 
array "smallstack" in binbuf_eval. I haven't measured so I have no idea if 
that's a premature optimization, though.
Also note: binbuf_eval already has an #ifdef for simply allocating for the 
entire message size, and the comment mentions decreased performance for 
whatever tests were run. I'm sure it would be worse performance for loading 
patches as those would almost be the worst possible case: large number of args 
where semis break the message up into fairly regular small chunks that would 
typically fit into an alloca or even a smallstack (e.g., "#X obj 20 20 bang;").
Random digression-- why doesn't t_binbuf just cache some annotations about 
itself like
* count for its longest nested message (e.g., contiguous region with no semis 
or commas* gpointer count* whether its a constant message (e.g., do we have 
dollar signs)
It appears every way to populate a t_binbuf already loops through the elements, 
*and* that they allocate memory there. Seems like users would see a performance 
increase by caching at least the maxnargs in the t_binbuf itself to avoid a 
full loop through the binbuf in binbuf_eval.
Constant message annotation could be nice, too. If a message box was just [1 2 
3 4 5( then the message could just do an end run around the message evaluation. 
(Of course that would add a branch for every message that isn't constant, so 
it'd need to be measured...)
-Jonathan  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

> On Sunday, May 12, 2019, 9:16:58 AM PDT, Christof Ressi 
>  wrote: 
 >> seems like using [declare] becomes unnecessary then...>> of course I think 
 >> library name prefix looks ugly, > there you have it :-) [declare -lib] is 
 >> here to stay.
You absolutely have to have [declare] and strongly encourage its usage.
The [declare] object hoists a message up to the top of the patch file to ensure 
that the declared libraries and paths get loaded *before* the rest of the patch 
file 
is evaluated. If users don't get comfortable using it to load externals then 
they 
quickly run into problems.

It also has an explicit and readable left-to-right ordering. If the user 
depends on 
implicit loading per external object box, the loading order is hidden and 
difficult to 
debug.
For example, imagine an external library which adds its own external loading 
mechanism, like pdlua. The user better load *that* before trying to load their 
own pdlua-based external, otherwise it won't create. Without using [declare] 
for 
that case, a user recently concocted a dynamic-patching solution to ensure 
ordering.

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

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

> On Sunday, May 12, 2019, 8:51:05 AM PDT, Christof Ressi 
>  wrote: 
 > anyway, I agree that ideally the structure of a library should be totally 
 > transparent to the user. >> Theoretically you could have a loader branch 
 > that would look for the "foo" binary in that case, load it, and then search 
 > for a "bar_setup" routine. > that's not a bad idea. doesn't seem too 
 > complicated to me. I might give it a shot.
I think what I'll do is to create a small external library in Purr Data to 
pentest the current myriad 
functions for external loading. Then I'll make some coverage tests.
Once you get a solid patch set I'll plug it in and see if it breaks anything.
-Jonathan
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

> On Sunday, May 12, 2019, 8:45:34 AM PDT, Christof Ressi 
>  wrote: 
 > ok, I see. you usually don't load individual classes with [declare -lib] but 
 > only (multi-objects-per-binary) libraries. > the workaround usually is to do 
 > [declare -path zexy -lib zexy]. -path is for abstractions and 
 > single-object-binaries and -lib is for the multi-object-per-binary library 
 > (if it exists).
How would a user without a full mental model of s_loader.c and m_class.c know 
to use the workaround?
However, that's a separate issue from your patch.

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

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

 > On Sunday, May 12, 2019, 10:58:52 AM EDT, Christof Ressi 
 >  wrote:
 
 >> that allows it to be built both as a single binary *or* with one class per 
 >> binary.
 > ah, of course that makes sense. >> with multi-binary style I can do [declare 
-lib foo/bar] whereas with the single-binary style that won't work. > I'm not 
sure I understand. Can give an example?
That's the libdir prefix logic. Say I have a "foo" library where one of many 
binaries inside "extra/foo/" is named bar.pd_linux. Then I can do [declare -lib 
foo/bar] to load that library.
On the other hand, if "foo" was compiled as a single binary with many classes 
inside it, then there is just "extra/foo/foo.pd_linux." In that case [declare 
-lib foo/bar] won't work.
Theoretically you could have a loader branch that would look for the "foo" 
binary in that case, load it, and then search for a "bar_setup" routine. But 
that's getting pretty damned complicated. And without a spec for what the 
loader is supposed to be doing in the first place I'd be hesitant to add that.

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

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

 > On Sunday, May 12, 2019, 12:27:33 AM PDT, Christof Ressi 
 >  wrote:
 
 >> So why aren't all (or at least nearly all) external developers simply using 
 >> "setup" as the entry point? 

> yes, I've asked that myself and I think they just could. Have a look at the 
> Max part of pd~: the setup function is simply called 'main'.

Here's the probable reason-- current practice is aimed at the maximally 
complicated library which has a makefile that allows it to be built both as a 
single binary *or* with one class per binary. In that case you must have 
uniquely-named setup functions per class that can be called from a central 
library setup.
Which I suppose would make more sense *if* the developer's choice of single- or 
multi-binary style was merely an implementation detail. But even with your 
patches it isn't-- with multi-binary style I can do [declare -lib foo/bar] 
whereas with the single-binary style that won't work.
-Jonathan  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

 > On Saturday, May 11, 2019, 10:09:00 PM EDT, Lucas Cordiviola 
 >  wrote:
 
 
> isn't it that :


> /* next try (objectname)/(classname).(sys_dllextent) ... */

> will load "foo/bar.pd_linux".
> This is correct right?
No, "objectname" refers to full string that was typed into the object box. So 
"foo/bar"
"classname" refers to the part after the rightmost slash-- "bar"
This combines for "foo/bar/bar.pd_linux" (for example).
You can test it with the "-verbose" flag. Try entering "foo/bar" in an object 
box and try to create it. You'll see "foo/bar/bar" with various extensions in 
the Pd window.
-Jonathan

> watch the "/" and "." :


> (something) / (something) . (extension)

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

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

Another question from the rabbit hole which I may have asked before-- what 
is up with the code after line 191 in s_loader.c:    /* next try 
(objectname)/(classname).(sys_dllextent) ... */

For [foo/bar], this would try to load "foo/bar/bar.pd_linux". I don't 
understand 
why the loader would try to do that.

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

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

> On Saturday, May 11, 2019, 5:25:25 PM PDT, Christof Ressi 
>  wrote: 
 >>  Does every supported PD platform allow you to a) dynamically load an 
 >>object that defines 
>> a previously defined symbol and b) search for a symbol starting from the 
>> last loaded 
>> object and going up the dependency chain to the containing object?
 
> I'm not sure if I understand your question. are you talking about C symbols 
> or Pd symbols here?

I'm talking about the system library on each OS responsible for dynamically 
loading
and searching objects into the running process. Like dlopen/dlsym

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

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

> On Saturday, May 11, 2019, 4:08:45 PM PDT, Christof Ressi 
>  wrote: 
"cyclone/gate" <-> "gate"). now if 'class_loadsym' *doesn't* match the 
classname we can assume that it's the name of a multi-object-per-binary 
library, prepend it to the classname and register that as an alternative 
creator. 
If a [declare -lib foo] is nested somewhere in [myAbstraction], wouldn't this 
algorithm erroneously add a 
"myAbstraction/foo" creator?
-Jonathan


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

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

 > On Saturday, May 11, 2019, 1:16:16 PM PDT, katja  
 > wrote:
 
 > On 5/11/19, Jonathan Wilkes via Pd-list  wrote:
[...]
>> 1. A cautious user will always leverage Pd's general collision avoidance by
>> prefixing your library's directory
>> name in the object box.

> Does prefixing with libdir name avoid collision?> Is it the case that Pd can 
> have classes like [cyclone/svf~] and [bsaylor/svf~] loaded > simultaneously?

Does every supported PD platform allow you to a) dynamically load an object 
that defines a previously defined symbol and b) search for a symbol starting 
from the last loaded object and going up the dependency chain to the containing 
object?

If the answer to both is yes, then the answer to your question is yes. If not, 
then we're forever stuck with "pddp/pddplink" and friends. (Unless there's a 
way to use something like the gcc constructor attribute on all platforms.)
-Jonathan
> Katja

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

Re: [PD] Full stop '.' in class namespace

[Jonathan Wilkes via Pd-list]

> On Friday, May 10, 2019, 5:51:20 AM EDT, Julian Brooks  
> wrote:  
 > Hi all,
> Is there a reason to not make use of a full stop in a namespace? 
> E.G. [julianslib.dac~]?
Hi Julian,
One problem is that it causes something like the double 
extra name collision avoidance problem.
1. A cautious user will always leverage Pd's general collision avoidance by 
prefixing your library's directory 
name in the object box.2. You, the developer, don't trust Pd's general 
collision avoidance to serve all possible 
user needs, so you prefix a library name in the creator string.
3. Now the cautious user must type `[ditters/ditters.karl]` to create your 
object.
-Jonathan

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

Re: [PD] [PD-announce] Purr-Data Google Summer of Code opportunity

[Jonathan Wilkes via Pd-list]

> On Wednesday, March 6, 2019, 12:32:12 PM EST, Chuckk Hubbard 
>  wrote:  
 > Re: GSoC for Purr Data, I just want to say> 1. That's great news! 
 > Congratulations!> 2. I saw the list, and while I'm sure some internal 
 > improvements would be good, for me, plugin integration would make a huge 
 > difference.
Hi Chuckk,
There's currently a fairly general project idea regarding plugin APIs. If you'd 
like to amend that one or add a new project 
idea, please make a merge request here:
https://git.purrdata.net/jwilkes/summer-of-code-ideas-list
If you add a new one I'd suggest keeping it fairly concise. That way the 
students will flesh out more of 
the details in their proposals.
The way GSoC works is that the students choose which project ideas they want to 
work on. (Or suggest their 
own.) Then they submit an application. Adding this idea to the list will 
increase the likelihood that someone 
chooses it. You can also try to seek out a student with the skills to complete 
it and persuade them to apply.
-Jonathan

> VST has unfortunately been completely removed from Csound in response to 
> Steinberg's aggressive approach, old CPS seems not to work anymore, and yes, 
> PD's plugin possibilities are unstable. There are Distrho PF and iPlug2 and 
> Faust, but none of these allow hosting, only being hosted. Other than that, 
> to write software that hosts as well as plugs VST, it's Juce or Steinberg's 
> SDK.A few years ago, it seemed like this functionality was cropping up 
> everywhere. Today it has disappeared. I for one would be thrilled to see this 
> happen.
On Tue, Mar 5, 2019, 9:10 PM Ivica Bukvic  wrote:

Greetings fellow Pd enthusiasts,
As some of you may be already aware, ast year the Purr-Data (a.k.a. Pd-L2Ork 
v2) was adapted to support native 64-bit operations. We are pleased to report 
that Purr-Data was once again selected this year as one of the GSoC projects. 
This means more opportunities to engage and help further the platform. Ideas 
for this year are plentiful, ranging from core infrastructure (C) development 
to patching and front-end development, including porting Pd-L2Ork's K12 
learning module that has seen its utilization in dozens of Maker camps over the 
past 7 years.
If interested, please contact Jonathan and/or me to explore potential projects 
and to discuss the next steps in the application process.
Best,
Ico-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
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

[PD] Purr Data 2.8.1 released

[Jonathan Wilkes via Pd-list]

Hi everyone,
Purr Data 2.8.1 is now available:

https://git.purrdata.net/jwilkes/purr-data#downloads

Changes:

* fixed a bug where the "Cancel" button would not work on the "Do you want
to save..." dialog
* added separate help files for [draw svg] and [table]. These used to
navigate directly to canvas-help.pd which is confusing for new users
* fixed a race by removing an old code path no longer needed by the
GUI. This could sometimes be triggered by creating a new object and
immediately clicking afterwards on a trackpad.
* fixed position of cat sprite in the "About Pd" patch. (Thanks to
nerrons for this one!)
* changed default font-size for new patches to 12 for improved
readability. This can be reverted back to size 10 font in the GUI
Preferences tab by removing the "-font-size 12" flag.

Please report any bugs:

https://git.purrdata.net/jwilkes/purr-data/issues

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

[PD] Purr Data 2.8.0 released

[Jonathan Wilkes via Pd-list]

Hi list,

Purr Data 2.8.0 has been released and is now available:

https://github.com/jonwwilkes/purr-data/releases/tag/2.8.0

Changes:

* Constrained dragging. Version 2.8.0 adds the ability to drag iemguis,
subpatches, graphs, grid, and Scope~, with a constraint either
vertically or horizontally. There are new cursors that show up when
the user moves the pointer along the bottom right-hand corners of
these objects. Clicking when the "east-west" cursor is displayed will
resize the widget in the horizontal direction. Clicking when the
"north-south" cursor is displayed will resize in the vertical direction.

Iemgui labels and the [cnv] object also allow constrained dragging.
Just move the pointer in the corners of the little "drag rectangle" that
appears when the relevant iemgui is selected. (The [cnv] object
and the red gop rectangle have two such "drag rectangles.")

* Fixed bug with scalar events. In some cases opening a subpatch
could unbind the event for the scalar.

* Improved help patch for [line] object. The new help file does a
better job explaining the function of the 3rd inlet and specifies
what happens when the grain size doesn't divide evenly into the
total ramp duration.

* Added a "footgun" GUI preset. A user stated that Max/MSP lets
the user selectively hide cords. Well, in Purr Data we let the user
hide _all_ cords and xlets with the "footgun" preset. The name is
self-documenting but may come in handy for patches with
so much spaghetti that the text in the object boxes is unreadable.

Please report all bugs on the issue tracker:

https://git.purrdata.net/jwilkes/purr-data/issues

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

Re: [PD] speed

[Jonathan Wilkes via Pd-list]

 > On Sunday, January 13, 2019, 4:16:38 PM EST, Roman Haefeli 
 >  wrote:

> I'm not sure I fully understand what your asking. Upon receiving a two-
float list, [line] starts sending out messages at the given rate. The
time period between the message reflects the second argument, except
for the time period between the second to last and last message where
the period might be shorter so that the sum of all grains equals the
ramp time given.
I don't believe you can deduce that behavior from the help file for [line]:
https://github.com/pure-data/pure-data/blob/master/doc/5.reference/line-help.pd

I think your description above is a much better response to the question of, 
"what is the algorithm" than the link you provided the OP.
It's also a better response to the question, "what is the behavior of [line]?" 
So I think it belongsin the help file for [line] (and I'll add something like 
it in Purr Data[1]).
-Jonathan
> Roman
[1] https://git.purrdata.net/jwilkes/purr-data/issues/498
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Status of PD double precision

[Jonathan Wilkes via Pd-list]

> Though Pd 0.49 compiled as above shows those small and large numbers,
it can't show all significant decimals in the GUI. This of course
limits the usefulness of double precision and also complicates the
interpretation of other tests.

Hi Katja,
Have you taken a look at Purr Data? AFAICT the number precision is correctly 
displayed in the GUI for the double precision builds.
If you want to play around with it you can compile using the toplevel makefile 
with `make light`. This will give you a deb or tarball with which you can 
install 
the basic Purr Data (core, pddp, and some others). It's about a 5 minute 
process 
on my Chromebook.

One outstanding question that came up was wrt table sizes for sqrt~ when 
compiling with PDFLOATSIZE=64:
http://disis.music.vt.edu/pipermail/l2ork-dev/2018-June/001985.html
Atm the same table size is used for both floatsizes.
Best,
Jonathan
> Katja  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Reason for not allowing '{' and '}' in Pd?

[Jonathan Wilkes via Pd-list]

 > On Monday, May 14, 2018, 7:34:24 AM EDT, Zack Lee  wrote:
 
 
 > Hi, I'm trying to add a Lua scripting feature for my external which will 
 > allow users to write and run Lua scripts directly in pd as object arguments 
 > similar to how [expr] object works.
I think I merged a patch from Albert for Purr Data to allow curly braces, 
probably for the case of pdlua.
-Jonathan  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pow/pow~ and negative input, a fix proposal

[Jonathan Wilkes via Pd-list]

> On Wednesday, May 9, 2018, 12:55:59 PM EDT, Martin Peach 
>  wrote: 
 
 On Wed, May 9, 2018 at 10:38 AM, Alexandre Torres Porres  
wrote:

You know, now that you the inability to deal with nan/inf in pd, such as in 
[select] came up, it makes total sense to avoid them in Pd and I can see where 
that comes from.
By the way, filtering out nan/inf is quite common in Max for audio signals, and 
in cyclone we needed to check that in objects like the trig functions (for 
instance  cyclone/atanh~ outputs 0 for input values <= -1 or >=1). And the case 
for doing that in audio signals is strong, as people say inf/nan is not good if 
it reaches your speakers and stuff.

I was still unsure about why doing that for cnotrol numbers as well, but what's 
the point in generating them if your system doesn't handle it well, right? In 
the case of [pow], "0" is a good limit value to clip your output, it makes 
sense since you can't get negative numbers but you can reach 0!


> I just tried this in Max6:> [pow 2] with a negative input gives a correct 
> positive result.
> [pow 0.5] with negative input sets a floatnumberbox to 'nan', but [print]s 
> the value '-1.#IND00'.> In max, neither of these works in a [sel].
And how about [pow~]-- what does it do in Max?
-Jonathan
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [until] ceiling

[Jonathan Wilkes via Pd-list]

 > On Thursday, April 26, 2018, 4:30:47 AM EDT, hans w. koch 
 >  wrote:
 
 
 > thanks orm and cyrille

> for forcing me to acknowledge, that i´ve indeed hit the IEEE ceiling here.
> i stubbornly tried to turn a blind eye to that...

> i am using pd 48-1 in 64bit but to my understanding internally it stil 
> computes single precision.
and the copy of pd-double floating around, doesn´t provide the lovely amenities 
of the text objects, on  which most of my operations rely.

There is a student working on double-precision t_float in Purr Data as part of 
GSoC this summer.
-Jonathan 
> maybe its finally time to look into python…

> all best
hans

> Am 26.04.2018 um 10:13 schrieb Orm Finnendahl 
> :
> 
> Hi Hans,
> 
> this is related to the integer precision of float numbers. In 32-bit
> pd to my knowledge single-floats as specified here are used:
> 
> https://en.wikipedia.org/wiki/IEEE_754
> 
> To be able to use bigger integers you can cascade more than one number
> (like hours/minutes/seconds in a clock), if you want to calculate aith
> these, implement abstractions for the needed mathematical functions,
> using e.g. list representations of the individual numbers as in/output.
> 
> Unfortunately this is also related to indexing into arrays limiting
> the maximum address.
> 
> Another solution could be to use 64-bit pd with double float
> resolution.
> 
> --
> Orm
> 
> 
> Am Donnerstag, den 26. April 2018 um 09:57:35 Uhr (+0200) schrieb hans w. 
> koch:
>> thanks, cyrille,
>> 
>> but why does the computation for 5pow12 [print start] in my patch then still 
>> produce 2.44141e+08?
>> or 5pow12 - 4pow12 work?
>> (see attached)
>> 
>> cheers hans
>> 
> 
> 
>> 
>>> Am 26.04.2018 um 09:46 schrieb cyrille henry :
>>> 
>>> hello,
>>> 
>>> this is not a probem with until, but a problem of big number precision.
>>> see attachment.
>>> cheers
>>> c
>>> 
>>> 
>>> Le 26/04/2018 à 09:30, hans w. koch a écrit :
 dear miller,
 all
 for a project i am working with very high number of iterations.
 but it seems i´ve literally hit a ceiling with [until]
 for 4pow12 iterations it performs fine.
 but 5pow12 doesn´t.
 feeding it into a counter,  5pow12 produces the same result as 4pow12.
 attached a small patch to demonstrate.
 is this limitation by purpose?
 (i have a workaround not using [until], but wanted to make sure i didn´t 
 overlook something)
 thanks
 hans
 ___
 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
> 


___
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] suggestion: $0 in messages

[Jonathan Wilkes via Pd-list]

 > On Tuesday, April 17, 2018, 8:10:47 AM EDT, Dan Wilcox 
 >  wrote:
 
 > Is this compatible with 
 > https://github.com/pure-data/pure-data/pull/347/files? Are there pros/cons 
 > between the implementations? 

Also-- the code I merged into Purr Data adds a binbuf_error routine which links 
evaluation errors to the relevant object.
Like when a user loads some monstrously large patch with many levels of nested 
abstractions and gets an error about an out-of-range argument. Now in Purr Data 
they can click a link to highlight the relevant message box (if it exists).
Finally, there's an additional branch that was merged after this to add some 
simple regression tests.
-Jonathan  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Jonathan Wilkes via Pd-list]

   > On Tuesday, April 17, 2018, 8:43:26 AM EDT, Christof Ressi 
 wrote:  
 > I am biased of course, but checking for t_message_responder class within 
 > canvas_getdollarzero seems a bit weird to me.
Yeah, it should probably be renamed to something like pd_getdollarzero. It's 
not a public function so it's easy to change.
-Jonathan

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

Re: [PD] suggestion: $0 in messages

[Jonathan Wilkes via Pd-list]

> On Tuesday, April 17, 2018, 8:10:47 AM EDT, Dan Wilcox 
 wrote:  
 > Is this compatible with 
 > https://github.com/pure-data/pure-data/pull/347/files? Are there pros/cons 
 > between the implementations? 
This implementation doesn't require a change to binbuf_eval's interface. It 
also caches a glist instead of the dollarzero value. That seems a little 
cleaner since glist is public data and dollarzero isn't.
Performance looks ok to me.
-Jonathan
  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Purr Data 2.5.1

[Jonathan Wilkes via Pd-list]

Hi list,
Purr Data 2.5.1 is now available:

https://git.purrdata.net/jwilkes/purr-data#downloads

Please report bugs here:

https://git.purrdata.net/jwilkes/purr-data/issues

Changes:
* speed up message box by removing the malloc/free per incoming message
* added regression test framework with some initial message box tests
* add linked errors in the console for message parsing errors. This allows you 
to "Find last error" for messages that don't have enough args, have a bad 
selector, etc. You can also click the link for the relevant error in the 
console to find them
* add "x" and "y" methods for [draw image]
* fix a regression with [pd~] (Thanks Albert!)
* add Vanilla version compatibility to "About Pd"
* build fix for make light (Thanks Giulio!)
* add more midi device slots to the Preferences dialog
Best,
Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Jonathan Wilkes via Pd-list]

> On Friday, April 6, 2018, 11:21:05 AM EDT, Christof Ressi 
>  wrote:  
 > here's an alternative implementation which uses no additional memory > 
 > allocations but is more invasive: 
 > https://github.com/pure-data/pure-data/pull/347
Here's the beginning of another implementation with some performance 
tests:https://git.purrdata.net/jwilkes/purr-data/merge_requests/199
  Performance looks decent on armv7l and it doesn't require changes to 
binbuf_eval.
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Jonathan Wilkes via Pd-list]

On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list 
<pd-list@lists.iem.at> wrote: 
 
 > I don't think it makes sense to have a malloc() and free() for each call to 
 > a msg box.
> Pd is already not very real-time friendly, why make it worse?
> There could be ...
> - statically allocated memory for t_gstack y in pd_pushsym
But you can nest arbitrarily deep in patch loading, no?
Also, patch loading time typically doesn't need to happen in realtime, as 
you're also allocating memory for objects during that time plus probably taking 
an i/o hit when loading abstractions.

On the other hand, it would be interesting to use a memory pool like you 
mention below and see its effect on load time. At least for the "canvas" field 
of data structures in Purr Data I cache the binbuf so there's no i/o hit there, 
only memory allocations.
 
> - a pre-allocated memory pool meant for short-lived memory allocations to be 
> used in real-time critical cases like this. If no memory available from the 
> pool, only then allocate it (or allocate a new pool). There are probably 
> other cases around the codebase where this would make sense, but why not 
> starting with this?

I'd measure performance here first to determine the best course of action.Even 
with a memory pool pd_pushsym is doing quite a few assignments. Pushing and 
popping on every msg box method may get be noticeably different than 
dereferencing a single cached value.
Measuring [trigger] performance I could see differences depending on how 
exactly the loop for the outlets was constructed.
-Jonathan

> Giulio

On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list 
<pd-list@lists.iem.at> wrote: 

> On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox <danomat...@gmail.com> 
> wrote: 

> test? https://github.com/pure-data/pure-data/pull/346

That will add a malloc/free for every method call to a msg box. So 
I'd measure the performance impact before using that 
implementation.

On the l2ork dev list I mentioned a potential way to cache the glist 
in the t_messresponder to avoid allocation at message evaluation time. 
But we haven't implemented that yet (nor measured the current 
performance hit).

-Jonathan






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

___
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] suggestion: $0 in messages

[Jonathan Wilkes via Pd-list]

>>What is wrong with [my_selector(--[list]--[$1(
> for instance, [42(--[list]--[$1( will give 42 not float, > similarly [symbol 
> crabs(--[list]--[$1( will give crabs not symbol > Also it seems reasonable to 
> just have 1 object box for querying a selector, > which is a main element of 
> the pd message environment.
That makes sense.
Are you after the literal selector in this case, or the one that the 
documentation implies should be there? For example, if I feed a list with a 
single floatarg (e.g., "list 42") to [selector] does it tell me the selector is 
"float" or "list"?

>>I don't understand what the word "solution" means here. If users have 
>>repeatedly requested msg box $0 to expand to glist's ce_dollarzero, why would 
>>Pd Vanilla give $0 in msg boxes a different function that is incompatible 
>>with object box $0?
> here "solution" means a good way to resolve $0 in message boxes..I don't 
> think what users request is necessarily the end all of reasons to implement a 
> feature in a language..
$0 in message boxes may be the most often requested feature for Pd. That 
certainly doesn't mean it has to be implemented.
But filling $0 with something completely unrelated is probably a good way to 
irritate your userbase for very little gain.

-Jonathan




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

Re: [PD] suggestion: $0 in messages

[Jonathan Wilkes via Pd-list]

>> whereas you cannot get an abstraction's selector (which would >> be handy 
>> for error reporting). 

> What is the selector of an abstraction? 
[my_abs arg1 arg2]
The selector is "my_abs".
The reason consistency probably keeps coming up is because everything on the Pd 
canvas as well as Pd files is just a Pd message. The possibility of learning a 
single set of rules for how messages behave is way easier than keeping track of 
special cases and inconsistencies.
So having a rule, "$0 expands to the first element of the argument vector," is 
great if the user can be guaranteed that the rule holds regardless of context 
of the evaluation.
On the other hand, suppose the rule is, "$0 expands to the first element of the 
argument vector UNLESS we're loading a canvas in which case it expands to a 
unique value to simulate locality with Pd's global binding mechanism." That's 
harder to reason about.
If you want $0 as selector in msg boxes
you could try to teach the inconsistency by reminding users that load time and 
message time are completely different contexts and therefore may have different 
expansion behaviors for dollarsign variables. But they're still going to notice 
that $1-n have *analogous* behavior in each context while $0 doesn't.
Anyhow, given the choice between an inconsistency that very few (if any) ask 
for in daily patching and one that a multitude of users have pleaded for in 
daily patching, I'm obviously in favor of the latter.

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

[PD] Purr Data 2.5.0

[Jonathan Wilkes via Pd-list]

Hi list,
Purr Data 2.5.0 is now available:

https://github.com/jonwwilkes/purr-data/releases/tag/2.5.0

Please report bugs here:

https://git.purrdata.net/jwilkes/purr-data/issues

Changes:

* add pd-lua library

* fix up dialog styling for GUI presets

* expand help browser search index to include the external library docs

* add preferences for setting when and from which docs the search browser 
creates an index

* port disis_munger~ to Purr Data from pd-l2ork 1.0 (experimental)

* fix the build scripts by adding toplevel makefile with new targets

* fix uninstall icon on Windows

* add dashed box around comments when in edit mode to show the maximum space 
they will take up
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] GSoC Student Application Deadline

[Jonathan Wilkes via Pd-list]

Hi list,
There are a few more days for students to apply to Google Summer of Code for 
this summer before the March 27 deadline.

Purr Data is one of the mentoring organizations. So if you are a student and 
would like to work on Purr Data this summer as part of GSoC, you can apply here:
https://summerofcode.withgoogle.com/
Our current project ideas are here:
https://git.purrdata.net/jwilkes/summer-of-code-ideas-list

The ones about streamlining Pd<->GUI communication and building a JIT compiler 
would be particularly useful for lots of users. But you can also propose your 
own new ideas, too.
If anyone has questions feel free to join the l2ork dev list and inquire:
http://disis.music.vt.edu/listinfo/l2ork-dev
Also, if anyone else wants to mentor let us know.
Best,Jonathan




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

[PD] Purr Data GSoC 2018

[Jonathan Wilkes via Pd-list]

Hi list,Purr Data was accepted as a mentoring organization for GSoC 2018!
We have an initial list of project ideas here:
https://git.purrdata.net/jwilkes/summer-of-code-ideas-list/blob/master/README.md
If anyone has some project ideas, interest in mentoring, or other feedback 
please join the l2ork devlist and give us your input:

http://disis.music.vt.edu/pipermail/l2ork-dev/2018-March/thread.html
Best,
Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] puredata parameters into HTML5

[Jonathan Wilkes via Pd-list]

> Dear list,
> I would like to connect puredata with a local webpage, not necessary uploaded 
> on a server.

> How can I send statistics generated by puredata into HTML5 code, so the page 
> immediately highlights the numbers, what PD calculates?

> Did anyone made something like this before?

There's a Google Summer of Code idea for adding this to Purr Data and some 
initial interest from a potential student:
https://git.purrdata.net/jwilkes/summer-of-code-ideas-list#api-for-html5-web-apps
-Jonathan

> Best,

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

Re: [PD] stale pointers after object creation (was Re: pix_data issue)

[Jonathan Wilkes via Pd-list]

> a glist (list of graphical objects) is internally implemented as a linked 
> list. usually, a big 

> advantage of a linked lists is that adding/deleting elements won't touch 
> other elements 

> (especially doesn't move them in memory, like it can happen with dynamically 
> sized arrays).

That's the theory.

In practice the insidious audio dropouts happen when Pd is 

*iterating* over a glist, not when adding/deleting objects.

This is because users learn relatively quickly the simple rule 

that adding/deleting objects rebuilds the signal graph, so they 

avoid doing that if at all possible during performance.

However, users generally have no idea what triggers a walk through 

the glist linked list. And those trips can easily cause dropouts 

during a performance-- even merely moving the mouse over a canvas.

So in practice, glist as linked list optimizes for the case not 

often used in realtime performance and is a detriment to performance 

in the cases where it matters (esp. compared to iterating over an 

array, though the number of glist iterations with things like 

mouse motion might trip up audio anyway).

-Jonathan

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

[PD] Purr Data 2.4.8 released

[Jonathan Wilkes via Pd-list]

Hi list,
Purr Data 2.4.8 is now available:

https://github.com/jonwwilkes/purr-data/releases/tag/2.4.8

Please report bugs here:

https://git.purrdata.net/jwilkes/purr-data/issues

Changes:
* refactor the GUI to get rid of some of the GUI freeze problems with various 
GUI widgets
* update wiringPi library used by disis_gpio class
* fix automatic list conversion for ancillary inlets
* fix glitch in dollar symbol matching with canvas "find" feature


-Jonathan

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

[PD] Purr Data 2.4.7 released

[Jonathan Wilkes via Pd-list]

Purr Data 2.4.7 is available:


https://github.com/jonwwilkes/purr-data/releases/tag/2.4.7

This is another bugfix release to keep Purr Data from freezing in certain 
situations with graph-on-parent patches* fix graph-on-parent issues with 
vumeter and radio objects
* clean up the readme (thanks to tiagomoraismorgado88 on github)
* fix function name (thanks to a. adhiyatma)


Please report bugs here:
https://git.purrdata.net/jwilkes/purr-data/issues

-Jonathan

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

[PD] Purr Data 2.4.6

[Jonathan Wilkes via Pd-list]

Hi List,A bugfix release for Purr Data is now available:
https://github.com/jonwwilkes/purr-data/releases/tag/2.4.6
This fixes a GOP crasher and a regression with events for nested data 
structures.
Please report bugs to:
https://git.purrdata.net/jwilkes/purr-data/issues
Best,
Jonathan

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

[PD] Purr Data 2.4.5

[Jonathan Wilkes via Pd-list]

Hi list,Purr Data 2.4.5 is available:
https://github.com/jonwwilkes/purr-data/releases/tag/2.4.5
Please report bugs here:
https://git.purrdata.net/jwilkes/purr-data/issues
Changes
* remove [midiclkin]* handle [draw] events correctly for nested data structure 
arrays
* improve the deb package build system by autogenerating most of the 
dependencies
* add [list store]
* protect against a segfault when a nested data structure array has element 
size of "0".
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Purr Data 2.4.4 released

[Jonathan Wilkes via Pd-list]

Hi list,Purr Data 2.4.4 is now available:

https://github.com/jonwwilkes/purr-data/releases/tag/2.4.4
Please report bugs here:
https://git.purrdata.net/jwilkes/purr-data/issues
Changes:* fixed dangling selection rectangle when a new patch window gains 
focus* added Pd Vanilla fudiparse and fudiformat classes* fixed crasher and 
consistency error with nested gops* fixed crasher when conforming a struct used 
as an array template in another struct* fixed display error with 
[moonlib/mknob] inside gop* fixed erroneous error message with [set]* various 
other GUI fixes for GOP
Best,Jonathan___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data window display

[Jonathan Wilkes via Pd-list]

> OK great that seems to have done the trick!  Does that mean xsample is not 
> compatible with Purr Data? The xsample objects do work once the patch loads 
> up.  Thanks for your help
I seem to remember flext-based externals spitting a bunch of tcl at the GUI. 
Purr Data is supposed 
to shuttle such things off to a short message that displays in the GUI to show 
the file, line number, 
and first few characters of the message. Since that isn't happening it may be a 
bug in Purr Data.

Can you zip up those xsample externals and send them to me?
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data window display

[Jonathan Wilkes via Pd-list]

Try removing the xsample libraries from your startup libs and see if you still 
get the bug.
-Jonathan


  From: school shoes 
 To: "pd-list@lists.iem.at" ; Jonathan Wilkes 
 
 Sent: Wednesday, November 15, 2017 12:39 AM
 Subject: Re: [PD] purr data window display
   
#yiv5648891961 #yiv5648891961 -- P 
{margin-top:0;margin-bottom:0;}#yiv5648891961 thanks for your reply ! 


> What is printed to the main Pd Window when you start Purr Data?


Welcome to Purr Data
GUI is starting Pd...
GUI listening on port 5400 on host 127.0.0.1
gui_path is /Applications/Pd-l2ork.app/Contents/Resources/app.nw
binary is /Applications/Pd-l2ork.app/Contents/Resources/app.nw/bin/pd-l2ork
Pd started.
incoming connection to GUI
canvasinfo: v0.1
stable canvasinfo methods: args dir dirty editmode vis
pdinfo: v.0.1
stable pdinfo methods: dir dsp version
classinfo: v.0.1
stable classinfo methods: size
objectinfo: v.0.1
stable objectinfo methods: class
[import] $Revision: 1.2 $
    [import] is still in development, the interface could change!
    compiled against Pd-l2ork version 2.4.3 (20171112-rev.4bd1b3a)
working directory is /Users/schoolshoes
mrpeach: can't load library
---
xsample objects, version 0.3.2pre

  xrecord~, xplay~, xgroove~   
  (C)2001-2014 Thomas Grill    
---


And when I right-click and "inspect background page" I get:

> a) right after starting Purr Data

nothing

> b) after trying to open a new patch for the first time

Uncaught SyntaxError: missing ) after argument list
    at perfect_parser 
(/Applications/Pd-l2ork.app/Contents/Resources/app.nw/pdgui.js:1696)
    at Socket. 
(/Applications/Pd-l2ork.app/Contents/Resources/app.nw/pdgui.js:1714)
    at emitOne (events.js:96)
    at Socket.emit (events.js:191)
    at readableAddChunk (_stream_readable.js:178)
    at Socket.Readable.push (_stream_readable.js:136)
    at TCP.onread (net.js:560)

perfect_parser    @    
/Applications/Pd-l2ork.app/Contents/Resources/app.nw/pdgui.js:1696
(anonymous)    @    
/Applications/Pd-l2ork.app/Contents/Resources/app.nw/pdgui.js:1714
emitOne    @    events.js:96
emit    @    events.js:191
readableAddChunk    @    _stream_readable.js:178
Readable.push    @    _stream_readable.js:136
onread    @    net.js:560

> c) after trying to open a new patch the second time


canvas mapping x100437130...     
/Applications/Pd-l2ork.app/Contents/Resources/app.nw/pdgui.js:1459


cheersFrom: Jonathan Wilkes 
Sent: Wednesday, 15 November 2017 11:18:48 AM
To: school shoes; pd-list@lists.iem.at
Subject: Re: [PD] purr data window display > Hi there , 

> I've noticed some strange behavior using Purr Data on macOs Sierra 10.12.5  
> (tested on purr data 2.4.2 and 2.4.3).

> After I first open the application, whatever I try to do first doesn’t seem 
> to display.

I can't seem to reproduce this.
What is printed to the main Pd Window when you start Purr Data?
Also, try right-clicking on the main Pd Window (or whatever the Mac equivalent 
is for right-clicking)
and choose "Inspect Background Page". Then click the "Console" tab and tell me 
if you get any
errors there:
a) right after starting Purr Datab) after trying to open a new patch for the 
first timec) after trying to open a new patch the second time
-Jonathan


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

Re: [PD] purr data window display

[Jonathan Wilkes via Pd-list]

> Hi there , 

> I've noticed some strange behavior using Purr Data on macOs Sierra 10.12.5  
> (tested on purr data 2.4.2 and 2.4.3).

> After I first open the application, whatever I try to do first doesn’t seem 
> to display.

I can't seem to reproduce this.
What is printed to the main Pd Window when you start Purr Data?
Also, try right-clicking on the main Pd Window (or whatever the Mac equivalent 
is for right-clicking) 
and choose "Inspect Background Page". Then click the "Console" tab and tell me 
if you get any 
errors there:
a) right after starting Purr Datab) after trying to open a new patch for the 
first timec) after trying to open a new patch the second time
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Purr Data 2.4.3 released

[Jonathan Wilkes via Pd-list]

Hi list,Purr Data 2.4.3 is now 
available:https://github.com/jonwwilkes/purr-data/releases
Report bugs here:https://git.purrdata.net/jwilkes/purr-data/issues
Changes:* fixes to [draw array] and [draw svg], plus some tutorials for using it
* fix bug where OSX 10.8 binary wouldn't work on 10.8 without editing plist
* fix regression with [draw g]
* improve [draw svg] getrect performance
* fix [stdout] so it works correctly with [pd~]
* fix [vu] display error
* added Debian Stretch binary
* simplify startup message
* port some documentation fixes from Pd Vanilla
* fix midi-help.pd, and add links for all midi-related objects
* fix font init bug triggered on some Windows systems
* (work-in-progress) canvas properties checkbox to suppress scrollbars
* (work-in-progress) canvas properties checkbox to suppress menus
* add mouse event callback outlet for [draw image]

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

Re: [PD] Purr Data 2.4.1

[Jonathan Wilkes via Pd-list]

> Looking here it doesn't seem so. https://launchpad.net/~dr-graef stops 
> at Zesty :-(
> He now has a test PPA for 17.10 here:
https://launchpad.net/~dr-graef/+archive/ubuntu/test

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

[PD] Purr Data 2.4.2 released

[Jonathan Wilkes via Pd-list]

Hi list,
A new release of Purr Data is available:

https://github.com/jonwwilkes/purr-data/releases

Please report bugs to

https://git.purrdata.net/jwilkes/purr-data/issues

* fixed freeze when flooding the Pd window with messages
* fixed array tick label positioning
* fix array trace line thickness so it is always visible
* send correct pointer for data structure array element event callbacks
* only redraw affect data structure array element when updating a field for 
[draw array]

Best,
Jonathan

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

Re: [PD] Purr Data 2.4.1

[Jonathan Wilkes via Pd-list]

>> I haven't tried yet. I'll see if I can get a 17.04 runner up for the next 
>> release (today or tomorrow). 
> What about 17.10? It's there where libgsl0ldbl and slv2-jack are missing

Oops, I misunderstood the Ubuntu LTS versioning scheme. I don't want to 
add another runner until the 18 series.
I'll see if Albert has a PPA for 17.10.
-Jonathan


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

Re: [PD] Purr Data 2.4.1

[Jonathan Wilkes via Pd-list]

> Any joy in setting it up?
I haven't tried yet. I'll see if I can get a 17.04 runner up for the next 
release (today or tomorrow).

> I tried on a different machine and still getting compilation errors.

What compilation errors? I thought you were reporting package installation 
errors.

-Jonathan

> Antonio



On 26 October 2017 at 19:31, Jonathan Wilkes  wrote:
> I'll try setting up a CI machine for 17.04 later...
>
> -Jonathan
>
>
> 
> From: Antonio Roberts 
> To: Jonathan Wilkes 
> Cc: Alexandre Torres Porres ; Pd-List
> 
> Sent: Thursday, October 26, 2017 5:58 AM
> Subject: Re: [PD] Purr Data 2.4.1
>
> I've tried compiling and there's a few missing packages that can't be
> installed.
>
> pd-l2ork : Depends: libgsl0ldbl but it is not installable or
>                      libgsl2 but it is not installable
>            Recommends: slv2-jack but it is not installable
> E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or
> specify a solution).
>
>
> On 25 October 2017 at 15:32, Jonathan Wilkes  wrote:
>
>> according to https://git.purrdata.net/ jwilkes/purr-data/issues/334#
>> note_3320
>
>
> That hasn't been updated in awhile.
>
> -Jonathan
>
>> 2017-06-22 5:06 GMT-03:00 Albert Gräf :
>
>
>> I've got a PPA for Ubuntu 17.04 up at my Launchpad page
>
>> (https://launchpad.net/~dr- graef/+archive/ubuntu/pd- l2ork.zesty). I
>> guess that it should work with Ubuntu Studio as well.
>
>
>
>
> --
> 
> anto...@hellocatfood.com
> http://www.hellocatfood.com
> 
>
>



-- 

anto...@hellocatfood.com
http://www.hellocatfood.com


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

Re: [PD] Purr Data 2.4.1

[Jonathan Wilkes via Pd-list]

I'll try setting up a CI machine for 17.04 later...
-Jonathan


  From: Antonio Roberts 
 To: Jonathan Wilkes  
Cc: Alexandre Torres Porres ; Pd-List 
 Sent: Thursday, October 26, 2017 5:58 AM
 Subject: Re: [PD] Purr Data 2.4.1
   
I've tried compiling and there's a few missing packages that can't be installed.

pd-l2ork : Depends: libgsl0ldbl but it is not installable or
 libgsl2 but it is not installable
    Recommends: slv2-jack but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).


On 25 October 2017 at 15:32, Jonathan Wilkes  wrote:

> according to https://git.purrdata.net/ jwilkes/purr-data/issues/334# note_3320


That hasn't been updated in awhile.

-Jonathan

> 2017-06-22 5:06 GMT-03:00 Albert Gräf :


> I've got a PPA for Ubuntu 17.04 up at my Launchpad page

> (https://launchpad.net/~dr- graef/+archive/ubuntu/pd- l2ork.zesty). I guess 
> that it should work with Ubuntu Studio as well.




-- 

anto...@hellocatfood.com
http://www.hellocatfood.com


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

Re: [PD] Purr Data 2.4.1

[Jonathan Wilkes via Pd-list]

> according to https://git.purrdata.net/jwilkes/purr-data/issues/334#note_3320


That hasn't been updated in awhile.

-Jonathan

> 2017-06-22 5:06 GMT-03:00 Albert Gräf :


> I've got a PPA for Ubuntu 17.04 up at my Launchpad page 

> (https://launchpad.net/~dr- graef/+archive/ubuntu/pd- l2ork.zesty). I guess 
> that it should work with Ubuntu Studio as well.

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

Re: [PD] Purr Data 2.4.1

[Jonathan Wilkes via Pd-list]

> Congrats!
> Do you know how to install it on Ubuntu 17.10? I tried installing the 16.04 
> binary but I get a bunch of dependency problems.

You could try compiling it:
https://git.purrdata.net/jwilkes/purr-data#linux
-Jonathan

> Antonio



On 23 October 2017 at 03:38, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at> 
wrote:

Hi list,
Purr Data 2.4.1 is out:
https://github.com/jonwwilkes/ purr-data/releases/tag/2.4.1

Please report bugs here:
https://git.purrdata.net/ jwilkes/purr-data/issues

* update [expr] family to the same codebase as Pd Vanilla 0.48
* fix bug that prevented file path in [draw image] from working
* fix regression opening Pd files in a running instance

Best,Jonathan

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





-- 

anto...@hellocatfood.com
http://www.hellocatfood.com


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

[PD] Purr Data 2.4.1

[Jonathan Wilkes via Pd-list]

Hi list,
Purr Data 2.4.1 is out:
https://github.com/jonwwilkes/purr-data/releases/tag/2.4.1

Please report bugs here:
https://git.purrdata.net/jwilkes/purr-data/issues

* update [expr] family to the same codebase as Pd Vanilla 0.48
* fix bug that prevented file path in [draw image] from working
* fix regression opening Pd files in a running instance

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

Re: [PD] initbang in vanilla (was Re: how to destroy/delete an object with dynamic patching?)

[Jonathan Wilkes via Pd-list]

> I see... somehow I got terribly confused and thought there was a 

> discussion to include it in vanilla, which would make sense to me.

There were many requests to include it in Pd Vanilla. Check 

the mailing list archives.

-Jonathan

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

Re: [PD] object names with "."

[Jonathan Wilkes via Pd-list]

>> why do you think you are missing something?

> I usually do that, cause I'm not a programmer
[...]


> I also see this pattern here and there, so I'm 

> not coming up with this, would anyone have something 

> against using "."?

You said above you are not a programmer above, so I'll 

thrown in a programming perspective in the hopes that 

it's useful to you:


Your preference complicates the source 

code for no significant usability gain. 

The relationship between [foo_bar] and foo_bar_setup is 

easy to see, whereas the one between [foo.bar] and 

setup_fooOx2ebar is not.


If the "." character were used in a library name because it 

represents a well-known mathematical operator that would 

be one thing. But using it for personal preference at the 

expense of code readability isn't a worthwhile tradeoff 

from the standpoint of maintainability.


It's possible you saw the pattern in an abstraction 

library where this issue doesn't come up.


Also-- I used an uppercase "o" instead of a zero just 

to drive the readability point home.


Best,
Jonathan

> cheers 

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

Re: [PD] object names with "."

[Jonathan Wilkes via Pd-list]

> Well, here's what I have, an object named [allpass.rev~]
As a practical matter, I still don't understand why you are trying 
to use "." instead of "_".
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] object names with "."

[Jonathan Wilkes via Pd-list]

> and how come underline works just fine?
Because Pd's loader mechanism searches for the symbol "${libname}_setup", 
where "${libname}" is the name of the library being loaded.
If you make sure that "${libname}" is drawn from the set of characters thatcan 
appear in a C function name, then users will be able to load your object 
in all the ways that Pd provides (using declare, using an absolute path name, 
etc.)
If instead you use characters that cannot appear in a C function name, you 
either limit the ways that users can load that library or require complicated 
workarounds like hexloader in order to make the library generally loadable.

> What other easy options do I have besides "_"?
Why do you want to avoid using an underscore?
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Purr Data 2.4.0

[Jonathan Wilkes via Pd-list]

Hello list,
Purr Data 2.4.0 is now out:

* fixed a bug where the preferences wouldn't load properly on some OSX systems
* added [draw svg] for a graphical viewport
* fixed display bugs with [draw image] and [draw sprite]
* added experimental [draw array] for visualizing array data


Binaries here:

https://github.com/jonwwilkes/purr-data/releases/tag/2.4.0

Report bugs here:

https://git.purrdata.net/jwilkes/purr-data/issues

-Jonathan

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

Re: [PD] why not Purr Data?

[Jonathan Wilkes via Pd-list]

>> On Mon, 2017-10-02 at 18:34 +, Jonathan Wilkes wrote:
>> > If supporting pure vanilla patches to their full extent would be a 
>> > stated goal of the Pure Data project, I'd have some incentive to
>> report 
>> > stuff, but it seems it isn't.
>> 
>> Supporting Pd Vanilla patches to their fullest extend is a goal of 
>> Purr Data.


> Up to which version? I'm asking about what you'd like to have reported 

> as bug and what rather not. The 'set' method to [dac~] was implemented 

> in Pure Data 0.47 (I guess) and is not yet supported in Purr Data. 


Please report it on the issue tracker:

https://git.purrdata.net/jwilkes/purr-data/issues
>> What are the crashers you are experiencing?

> Re weird looking patches and unusuable GUIs: the flag -legacy pretty
> much nails it. Most of the patches I tested look good and work well.
> Two issues I encountered regarding the GUI part:


> 1) In Pure Data in a group of overlapping widgets, the lowest one grabs 

> the mouse commands (which is probably not a design decision, but it 

> proved helpful for certain hacks). In Purr Data, the most top one grabs 

> the mouse, which breaks such patches created in Pure Data. I'm not 

> proposing to change that behavior, as it probably seems more logical to 

> most users the way Purr Data does it, I'm simply pointing out 

> differences. 


Do you have patches which rely on that?


> 2) A self-made abstraction (GOP widget) that lets you scroll through a 

> list of and select an item, doesn't work well in Pure Data. Instead of 

> showing only the label of the last selected item, all labels stay and 

> thus end up in a black block after a while. I haven't investigated the 

> root cause yet.


Hard to tell without looking at it:

https://git.purrdata.net/jwilkes/purr-data/issues

> Re crashes. I do experience some crashes, for instance when loading 

> certain netpd sessions (which does quite a lot of things including but
> not limited to  dynamically creating abstractions). But I haven't 

> investigated yet why. It may be due to an external I use which comes in 

> a different version in Purr Data.

> I will report back when I more useful data.


Thanks,
Jonathan

> 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

[PD] Purr Data 2.3.3 released

[Jonathan Wilkes via Pd-list]

Hi list,

Purr Data 2.3.3 is out.

* improve performance of ggee/image
* allow loading jpegs in Gem under Windows


Releases here:
https://github.com/jonwwilkes/purr-data/releases/tag/2.3.3

Report bugs here:

https://git.purrdata.net/jwilkes/purr-data/issues

-Jonathan

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

Re: [PD] purr data 2.3.2's gem on windows 10

[Jonathan Wilkes via Pd-list]

> Hello Jonathan and Alexandre ,

> i just saw the git commits  .
> but will wait for next build. 
> or try a build next week. 

> i already tried but failed miserably :-) 
> i 'll retry and give feedback,  

> i justed wanted to ask if your modifications will give support for 
> avi? 
> mpg? 
> quicktime?

It adds jpeg support. (Plus some other fixes unrelated to Gem.)

> to prepare some files.
> and for images, png support with alpha channel for transparency or tiff or 
> tga.
> or , if possible , support for 
> https://www.xnview.com/fr/GFL/ 
> or a libre alternative like imagemagick?

> i am for the moment trying things with osc and vision software Scene.

> and html interface in purrdata supports a higher load of messages for display 
> than tcl tk . 

> on linux (mint) it works great for me on an old  pentium dual core laptop 

> but opengl is too old and slow, just ok for tests


What's too slow?


> btw, is it possible to send a html patch window to a secondary monitor 
> fullscreen? 

> and/or to use webgl?. 

> I would like to deploy installation in a classroom, for initiations.

Have you tried pulling the window over to the secondary screen and clicking 
"Fullscreen" 

in the "View" menu?


-Jonathan

> after all, i was led to linux by windows pd crashes.
> an all new world.

> Thanks 

> Pierre-Yves




2017-09-30 17:10 GMT+02:00 Jonathan Wilkes :

> Hello List,
>
>> 1. Please don't ask why i use windows.
>
>> 2. please tell me if there is a better place to post about this.
>
>> 3. i installed purr-data 2.3.2 (and other versions before) on windows 10 
>> (x64).
>
>> gem is included but i startup i get :
>> GEM: image loading support: SGI
>
>> only
>
>> and i can't find a way of loading jpg or movies in gem.
>
>> if i load example pix_film opr pix_movie, i get
>
>> verbose( 0):[pix_movie]: AVI support verbose( 0):[pix_movie]: image support
>
>> [pix_film]: unable to open file: C:/Users/PC-VonoXS/Desktop/ pour 
>> josep/capture014_type1.avi
>
>> (standard dv file , that used to work on pd-extended)
>
>> but gem 93.3 is quite old , especially for glsl stuff.
>
>
>Hi Py,
>I maintain Purr Data. I'll have a look at this.
>
>-Jonathan
>

___
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] Fwd: Re: why not Purr Data?

[Jonathan Wilkes via Pd-list]

> So basically I guess you're telling me that I should either 1) upgrade to a 
> faster mac 
> or 2) move from using PurrData to using PureData Vanilla, to get rid of the 
> GOP-within-GOP-within-GOP -induced CPU spikes and high CPU usage I've been 
> having with my mid-2009 MacBookPro with PurrData?
Not sure at whom that is directed, but I'm definitely not saying that.

Post a trivial example patch on the tracker and I'll have a look and see if I 
can fix it:
https://git.purrdata.net/jwilkes/purr-data/issues
-Jonathan



On 3 October 2017 at 20:28, Alexandre Torres Porres  wrote:



2017-10-03 14:08 GMT-03:00 Jonathan Wilkes :

I'd be much more interested in a feature that automatically encapsulates the 
current selection inside an abstraction.

This is exactly what I believe I've seen a while back, maybe in pd-l2ork 1.0? 
There was even an youtube video showing it? My mind is tricking me into 
believing I even tried it myself and saw that it worked in Purr Data. How crazy 
am I?
cheers
__ _
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/ 
listinfo/pd-list





-- 
http://linkedin.com/in/esaruoho // http://twitter.com/esaruoho // 
http://lackluster.bandcamp.com //+358403703659 // http://lackluster.org // 
skype:esajuhaniruoho // iMessage esaru...@gmail.com 
//http://esaruoho.tumblr.com // http://deposit4se.tumblr.com // 
http://facebook.com/LacklusterOfficial //

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

Re: [PD] Fwd: Re: why not Purr Data?

[Jonathan Wilkes via Pd-list]

> I like how Pd-l2ork/Purr Data has many new features, like infinite undo, 
> arrays with bars. By the way, what's the shortcut to 
> automatically encapsulate a part of your patch as a subpatch in pd-lork/purr 
> data? I saw something once where you could select 
> a portion of the patch and do it.

That feature doesn't currently exist, though it's fairly trivial to implement. 
(I believe 
DesireData had it.)

I'd be much more interested in a feature that automatically encapsulates the 
current selection 
inside an abstraction.
-Jonathan

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

Re: [PD] why not Purr Data?

[Jonathan Wilkes via Pd-list]

> I will let you know as soon as I'm on a machine that I can install a 
> pre-compiled deb package of Purr Data on. Unfortunately, my personal 
> laptop is still running Ubuntu 16.04 i386 because I've been upgrading 
> for a couple of years and I never installed from scratch.
Oh, I see. No rush, then.
I thought you were talking about recent crashes.
Best,Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] why not Purr Data?

[Jonathan Wilkes via Pd-list]

> If supporting pure vanilla patches to their full extent would be a 
> stated goal of the Pure Data project, I'd have some incentive to report 
> stuff, but it seems it isn't.

Supporting Pd Vanilla patches to their fullest extend is a goal of 
Purr Data.
What are the crashers you are experiencing?
-Jonathan

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

Re: [PD] why not Purr Data?

[Jonathan Wilkes via Pd-list]

> Great the Jonathan has joined this thread.
> What keeps Purr data from running the latest pd core (0.48) and leaving aside 
> things that Purr can do that vanilla 
> can't (i.e. $0 in message box), are there any concerns going the other way?
> i.e. basic things that vanilla can do that Purr cant?
Look at the set of features that were added in Pd Vanilla 0.48. Those features 
are not yet 
available in Purr Data.
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] why not Purr Data?

[Jonathan Wilkes via Pd-list]

> Purr Data looks like a continuity of pd-extended, anyway all pd versions 
> are obsolete since they aren't fully 64bit compatible.
Do most audio devices now require a 64-bit driver under Windows?
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] why not Purr Data?

[Jonathan Wilkes via Pd-list]

> Many of my patches that I developed on Pure Data don't run without 
> modification in Purr Data. Some crash at loading, some look graphically 
> weird
Typically, "crashers" and "freezers" get fixed pretty quick in Purr Data.
The only freezer I remember with one of your patches was due to a 
broken object triggering an infinite loop in your patch's [until] object. I'm 
pretty sure that was an alpha or beta version, and I'm pretty sure I fixed 
whatever object it was that wouldn't create.
I don't see any other relevant crashers listed on the tracker:

https://git.purrdata.net/jwilkes/purr-data/issues
What am I missing?

-Jonathan




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

Re: [PD] why not Purr Data?

[Jonathan Wilkes via Pd-list]

> thanks everyone, this is really helpful.


> in light of your experiences, it seems like the best of all worlds might 

> be to use a modern computer/os with Purr Data for editing, make sure to 

> stick with vanilla only objects, and use vanilla for deploying.  

Just for reference-- I developed Purr Data on a Lenovo X60 which I believe 

was modern in 2006. OS was Ubuntu 14.04. I could get 60fps doing silly data 

structure animations without audio dropouts. Granted, that was a trivial audio 

chain.

-Jonathan


> anyone see any potential pitfalls there?
> -ali

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

Re: [PD] purr data 2.3.2's gem on windows 10

[Jonathan Wilkes via Pd-list]

> Hello List,

> 1. Please don't ask why i use windows.

> 2. please tell me if there is a better place to post about this.

> 3. i installed purr-data 2.3.2 (and other versions before) on windows 10 
> (x64).

> gem is included but i startup i get :
> GEM: image loading support: SGI 

> only

> and i can't find a way of loading jpg or movies in gem.

> if i load example pix_film opr pix_movie, i get 

> verbose( 0):[pix_movie]: AVI support verbose( 0):[pix_movie]: image support

> [pix_film]: unable to open file: C:/Users/PC-VonoXS/Desktop/pour 
> josep/capture014_type1.avi

> (standard dv file , that used to work on pd-extended)

> but gem 93.3 is quite old , especially for glsl stuff.


Hi Py,
I maintain Purr Data. I'll have a look at this.

-Jonathan

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

[PD] Purr Data 2.3.2

[Jonathan Wilkes via Pd-list]

Hi List,Purr Data 2.3.2 is now available:
https://github.com/jonwwilkes/purr-data/releases/tag/2.3.2
Please report bugs here:
https://git.purrdata.net/jwilkes/purr-data
This release fixes the "-unique" flag for running multiple 
instances, fixes [pd~] on Windows, and fixes a GUI bug 
and some errors in a data structure demo game.
-Jonathan





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

Re: [PD] purr data duplicate undo

[Jonathan Wilkes via Pd-list]

> Hey -
> every now and then using purr data i find that i have inadvertently made 
> duplicate objects/msgs etc> that are directly in front of each other.

> I've finally figured out that this is happening with the following sequence:  
> cmd +d , cmd+z

I see. It appears the undo history gets generated from the implementation of 
"Duplicate"-- instantiate 
a duplicate object AND THEN displace it by (10, 10)-- rather than the 
functionality of "Duplicate"-- 
make a new object displaced by (10, 10).
I went ahead and made an issue for 
this:https://git.purrdata.net/jwilkes/purr-data/issues/370

> in pd vanilla the same combination simply undoes the duplicate command, which 
> is probably the 
> expected behavior. But in purr data it doesn't delete the duplicate, but 
> moves it directly in front of the original. 

> Not sure if this is a bug, but thought i’d bring it up as a couple of times 
> has led to some time consuming 
> trouble shooting, because duplicate objects sitting directly on top of the 
> original can look like they are connected 
> to things when they are not.

In the meantime, if you want to check for these obscured objects you can select 
all and then 
choose "Tidy Up" from the "Edit" menu. Any obscured objects should then be 
re-situated below 
the original object. You might also get unwanted repositionings for other parts 
of the patch, but 
you can easily undo those after finding the duplicated objects.
-Jonathan

> using purr data 2.3.0 on macos sierra

> cheers, 
> ss



___
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] Purr Data 2.3.0 released

[Jonathan Wilkes via Pd-list]

> 2017-08-23 15:03 GMT-03:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>:

Hi list,
Purr Data 2.3.0 is out:

https://github.com/jonwwilkes/ purr-data/releases

> hey, I realize this is a github link, do you take merge requests from there?
No.
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Purr Data 2.3.0 released

[Jonathan Wilkes via Pd-list]

Hi list,
Purr Data 2.3.0 is out:

https://github.com/jonwwilkes/purr-data/releases

Report issues here:
https://git.purrdata.net/jwilkes/purr-data/issues

-Jonathan

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

Re: [PD] hexloader incorporated into vanilla?

[Jonathan Wilkes via Pd-list]

> Howdy, don't think this has ever been discussed... sorry if it had.

> So, we need externals with non-alphanumeric names to be loaded into a 
> multi-object library, loaded via start up. If you have them as a set of 
> single-object binaries, the only option seems to be [hexloader] (a third 
> party external). Hence, in order to reduce dependency on third party 
> externals, would there be any opposition in the idea of incorporating the 
> hexloader code into Pd Vanilla? 

> An alternative could be 'deken' handling dependencies, so if you download one 
> external pack it would also download a dependency such as 'hexloader'.

> thoughts?

Sorry, I just noticed this message.
Pd's default loader mechanism has a "hexloader" in it.
Curious-- if the user tries to create [foo], what is the use case for the 
default loader 
trying to load "foo/foo.$pd_extension" and "foo/foo.pd"?

-Jonathan

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

Re: [PD] New users and external path struggles

[Jonathan Wilkes via Pd-list]

>> None will clash with the others.

> that's also true for Pd vanilla!

Yes-- the class loader behavior I described is part of the 
Pd vanilla codebase.
-Jonathan   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Jonathan Wilkes via Pd-list]

> yeah, this worked because of libdir. 

A few details:

* The Pd extended libdir loader searches for a $LIBNAME-meta.pd file. If 
it finds it it adds the directory containing it to the global search path.* 
namespace prefixes (probably better referred to as directory prefixes) will 
add the prefixed name to Pd's object creator methodspace.
So if you do 
this:[foo/image][bar/image][/home/foo/decade_old_version/build/bin/image]
None will clash with the others.
(Of course if you have /home/foo AND /home/bar/foo in your search path 
then you are right back to depending on path search order...)
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Symbol box interface improvement suggestion

[Jonathan Wilkes via Pd-list]

> Hey all

> So often I see people getting confused with symbol boxes. Its current 
interface design is contrary to what most people are used to from other 
software. Every text entry that I can think of gives a visual cue to 
indicate keyboard input is expected. However, when you click symbol 
box, nothing happens, which is the confusing part and makes a lot of 
people think it's not working. Only when you start typing, it adds a 
temporary '...' suffix to the written input.
At least in Purr Data, the color of the text changes to show that the 
symbol/number box has been activated.

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

Re: [PD] your favorite key:value data structure?

[Jonathan Wilkes via Pd-list]

> By default, "search" matches only lines whose first field(s) match the search 
key(s).  OTOH, if you have a duplicate key and want to find anything besides 
the 
first occurence of the key it will be tricky.

Could also just reimplement dogensym in Pd. :)
-Jonathan

> cheers
> Miller





   #N struct 1003-values text buf;
#N struct 1003-dict float x float y array a 1003-values;
#N canvas 401 34 484 597 10;
#N canvas 551 134 450 323 \$0-values 0;
#X obj 72 44 struct \$0-values text buf;
#X restore 172 47 pd \$0-values;
#N canvas 288 224 449 324 hash 0;
#X obj 133 22 inlet;
#X obj 133 74 list fromsymbol;
#X obj 133 138 +;
#X obj 133 160 t a;
#X obj 133 182 +;
#X obj 133 204 t a;
#X obj 118 243 f;
#X obj 118 265 &;
#X obj 384 27 inlet;
#X obj 384 49 - 1;
#X obj 118 287 outlet;
#N canvas 0 0 450 300 list-drip 0;
#X obj 69 88 t a a;
#X obj 69 245 spigot;
#X obj 108 153 bang;
#X obj 108 172 1;
#X obj 229 153 route bang;
#X obj 189 154 bang;
#X obj 189 173 0;
#X obj 108 118 list split 2;
#X obj 238 383 list split;
#X obj 305 332 list length;
#X obj 305 354 >> 1;
#X obj 69 264 t a a a a;
#X obj 69 450 list split;
#X obj 136 402 list length;
#X obj 136 427 >> 1;
#X obj 37 23 inlet;
#X obj 296 179 outlet;
#X text 79 23 Copyright 2009 by Mathieu Bouchard;
#X obj 37 57 t b a;
#X obj 471 123 outlet;
#X text 526 125 signal end of list;
#X text 387 27 made compatible with [list-drip]: fbar 2009;
#X connect 0 0 1 0;
#X connect 0 1 7 0;
#X connect 1 0 11 0;
#X connect 2 0 3 0;
#X connect 3 0 1 1;
#X connect 4 1 16 0;
#X connect 5 0 6 0;
#X connect 6 0 1 1;
#X connect 7 0 2 0;
#X connect 7 2 4 0;
#X connect 7 2 5 0;
#X connect 8 0 0 0;
#X connect 9 0 10 0;
#X connect 10 0 8 1;
#X connect 11 0 12 0;
#X connect 11 1 13 0;
#X connect 11 2 8 0;
#X connect 11 3 9 0;
#X connect 12 1 0 0;
#X connect 13 0 14 0;
#X connect 14 0 12 1;
#X connect 15 0 18 0;
#X connect 18 0 19 0;
#X connect 18 1 0 0;
#X restore 133 101 pd list-drip;
#X obj 133 44 trigger anything bang;
#X obj 249 116 f 0;
#X connect 0 0 12 0;
#X connect 1 0 11 0;
#X connect 2 0 3 0;
#X connect 3 0 2 1;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
#X connect 5 0 4 1;
#X connect 5 0 6 1;
#X connect 6 0 7 0;
#X connect 7 0 10 0;
#X connect 8 0 9 0;
#X connect 9 0 7 1;
#X connect 11 0 2 0;
#X connect 11 1 6 0;
#X connect 12 0 1 0;
#X connect 12 1 13 0;
#X connect 13 0 2 1;
#X connect 13 0 4 1;
#X restore 224 298 pd hash;
#N canvas 240 343 450 323 \$0-dict 0;
#X obj 167 120 filledpolygon 900 0 1 0 0 20 0 20 20 0 20;
#X obj 89 34 struct \$0-dict float x float y array a \$0-values;
#X restore 172 24 pd \$0-dict;
#N canvas 289 250 450 300 \$0-data 0;
#X restore 170 71 pd \$0-data;
#N canvas 555 302 450 346 \$0-init-data 0;
#X obj 101 80 f \$0;
#X msg 128 126 clear \, scalar \$1-dict 5 5;
#X obj 128 148 s pd-\$0-data;
#X obj 101 56 inlet;
#X obj 101 102 t a a;
#X obj 101 197 pointer;
#X obj 101 219 outlet;
#X msg 101 175 traverse pd-\$1-data \, next;
#X connect 0 0 4 0;
#X connect 1 0 2 0;
#X connect 3 0 0 0;
#X connect 4 0 7 0;
#X connect 4 1 1 0;
#X connect 5 0 6 0;
#X connect 7 0 5 0;
#X restore 273 46 pd \$0-init-data;
#X obj 273 24 loadbang;
#X obj 273 68 trigger bang pointer;
#X msg 273 93 1024;
#X text 307 92 hashtable size;
#X obj 291 347 element \$0-dict a;
#X obj 197 387 text search -s \$0-values buf;
#X obj 273 126 setsize \$0-dict a;
#X obj 197 413 sel -1;
#X obj 178 477 text set -s \$0-values buf;
#X msg 197 435 1e+06;
#X obj 170 184 t a a;
#X obj 197 230 t a a;
#X obj 197 206 list split 1;
#X obj 171 135 inlet;
#X obj 171 157 list;
#X obj 79 135 inlet;
#X obj 79 157 list split 1;
#X obj 112 507 text get -s \$0-values buf;
#X obj 79 422 f;
#X obj 79 179 t b a a;
#X obj 79 444 sel -1;
#X obj 79 555 outlet;
#X text 81 111 READ;
#X text 172 110 WRITE;
#X text 23 19 2017 Jonathan Wilkes;
#X obj 112 529 list split 1;
#X connect 1 0 9 0;
#X connect 4 0 6 0;
#X connect 5 0 4 0;
#X connect 6 0 7 0;
#X connect 6 1 9 1;
#X connect 6 1 11 1;
#X connect 7 0 1 1;
#X connect 7 0 11 0;
#X connect 9 0 10 1;
#X connect 9 0 13 3;
#X connect 9 0 22 3;
#X connect 10 0 12 0;
#X connect 10 0 23 1;
#X connect 12 0 14 0;
#X connect 12 1 13 1;
#X connect 14 0 13 1;
#X connect 15 0 13 0;
#X connect 15 1 17 0;
#X connect 16 0 10 0;
#X connect 16 1 1 0;
#X connect 17 0 16 0;
#X connect 18 0 19 0;
#X connect 19 0 15 0;
#X connect 20 0 21 0;
#X connect 21 0 24 0;
#X connect 22 0 30 0;
#X connect 23 0 25 0;
#X connect 24 0 23 0;
#X connect 24 1 10 0;
#X connect 24 2 1 0;
#X connect 25 0 26 0;
#X connect 25 1 22 0;
#X connect 30 1 26 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] your favorite key:value data structure?

[Jonathan Wilkes via Pd-list]

> Hello Jonathan,

> Thanks for your reply.
> I'm not quite sure what you mean.

> What pd-vanilla object do you use to implement "Variable number of keys of 
> arbitrarily typed values" 
[text], [coll], etc.

> or "set number of keys with set value types"?data structures

The benefit of the latter is that you know the number of "slots" ahead of time 
so you can populate 
the data without needing to allocate memory.

> I should add that I'm interested ultimately in a data structure that I can 
> populate from text files, read by PD.

In that case I don't think the benefit I mentioned wrt data structures matters 
because 
the I/O speed will be your limiting factor.

My suggestion would be to start with the more expressive vanilla object-- 
[text]-- and see 
if it fulfills your needs. Keep in mind though that it is at core not a 
key/value store but instead 
a 2-dimensional array of atoms. E.g., you can decide that the first item in 
each line is your 
key, but the text class interface does nothing to prevent you from adding more 
lines that 
duplicate that same key.

-Jonathan

> -ali


On Tue, Jul 18, 2017 at 1:16 PM, Jonathan Wilkes  wrote:

Variable number of keys of arbitrarily typed values, or 
set number of keys with set value types?
-Jonathan


  From: Ali Momeni 
 To: Pd-List  
 Sent: Tuesday, July 18, 2017 1:09 PM
 Subject: [PD] your favorite key:value data structure?
  
Hello all,
I'm looking for something analogous to the Max "coll" object, or a python 
dictionary, or anything with key value pairs.  
I'm aware of the 'cyclone' and its 'coll' object.
i'm wondering if there is a pd-vanilla friendly alternative to this 3rd party 
external.
any hints?
thanks in advance,
ali__ _
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] your favorite key:value data structure?

[Jonathan Wilkes via Pd-list]

Variable number of keys of arbitrarily typed values, or 
set number of keys with set value types?
-Jonathan


  From: Ali Momeni 
 To: Pd-List  
 Sent: Tuesday, July 18, 2017 1:09 PM
 Subject: [PD] your favorite key:value data structure?
   
Hello all,
I'm looking for something analogous to the Max "coll" object, or a python 
dictionary, or anything with key value pairs.  
I'm aware of the 'cyclone' and its 'coll' object.
i'm wondering if there is a pd-vanilla friendly alternative to this 3rd party 
external.
any hints?
thanks in advance,
ali___
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-announce] pd 0.48-0test1 released

[Jonathan Wilkes via Pd-list]

> The "bad" behavior is that, fro instance, 0 in gives 1 out.  That happened 
on everyone's machine except mine (so I was blissfully unaware that anything 
was wrong).  I'm running fedora linux.  Even debian linux machines gave the 
wrong answer while my machine kept giving me the right one.  Im not going 
to try to figure out what the #$&^ was going on :)

If someone can point clearly to the source of undefined behavior in that 
seemingly simple code then it would seem appropriate to just fix the bug 
and move on.

Otherwise it appears to be deterministic bug (excepting one unexplained 
edge case) that almost certainly has resulted in patches out in the wild 
behaving 
and/or sounding one way and not another. A compatibility case seems warranted 
for this.
-Jonathan

> M



On Sun, Jul 16, 2017 at 06:51:03PM +0000, Jonathan Wilkes via Pd-list wrote:
> > That's just the question - is it worth keeping an old bug available for 
> compatibility?  In this case, perhaps yes - although you'd have to 
> explicitly set a compatibility flag in Pd to get eh old behavior.
> 
> > (incidentally teh old behavior was machine-dependent - this complicates it 
> even further :)
> I didn't notice that it's machine-dependent-- it just appears as the wrong 
> algorithm 
> to me.
> 
> Is there undefined behavior there?
> -Jonathan

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