[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

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/05/2018 12:36 AM, IOhannes m zmölnig wrote:
> repeat the test with two abstractions having loading libraries providing

this should of course read: "having loading libraring providing".
it's getting late...

gfasmrd
IOhannes



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

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
> 
> The compiled object from the lib listed in the path doesn't get called, and
> the one specified in [declare] gets called instead.
> 

repeat the test with two abstractions having loading libraries providing
the same object.
e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd
uses a [gate] stub that prints "gate 2".
load abs1.pd, after that abs2.pd (either manually, or by putting them
into a master patch). observe the console.

fgamdsr
IOhannes




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

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

how so? please elaborate...

In my example I had a dummy abstraction in a lib listed in the path, but
declare made it not call it.

are you saying this only happens cause it is an abstraction?

Because I made the test with a compiled object and I got the same
behaviour, no difference!

The compiled object from the lib listed in the path doesn't get called, and
the one specified in [declare] gets called instead.

cheers


2018-01-04 20:03 GMT-03:00 IOhannes m zmölnig :

> On 01/04/2018 11:56 PM, Alexandre Torres Porres wrote:
> > Therefore, using [declare] will avoid name collisions and not the
> opposite.
>
> only for abstractions.
>
> gfadsmr
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/04/2018 11:56 PM, Alexandre Torres Porres wrote:
> Therefore, using [declare] will avoid name collisions and not the opposite.

only for abstractions.

gfadsmr
IOhannes



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

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-04 18:41 GMT-03:00, Christof Ressi :
>> (is there a difference in behaviour between them?)
>
> stdlib is relative to the 'standard paths' whereas path is relative to the
> current patch.
>
> my point is that the user could have their libraries in a totally different
> place so that none of [declare -path/-stdpath/-lib/-stdlib cyclone] will
> work.

I see, but this is kinda parallel, and we're currently discussing
changes to how the path works, as I referred to in the links I sent
before.

What I'm just questioning is wether using [declare] will force and
avoid name collisions. I went ahead and made a test to make sure if
what I said actually happens.

So, I created a dummy abstraction named gate, put it inside a library
that is listed in the path’s preferences, then I took cyclone out of
the listed paths.

Then what happens when I call [gate] is that it finds this dummy
abstraction instead!

Now, what I did next is I added [declare -path cyclone] (no -stdpath)
and [declare] now forces it to find [gate] from cyclone instead.

So, yeah, this is what I said it’d would and should do, so I checked
and it does happen for me.

Therefore, using [declare] will avoid name collisions and not the opposite.

cheers



>
> Gesendet: Donnerstag, 04. Januar 2018 um 22:14 Uhr
> Von: "Alexandre Torres Porres" 
> An: "Christof Ressi" 
> Cc: pd-l...@mail.iem.at
> Betreff: Re: Re: [PD] declare vs. namespaces - current best practice
>
>
> 2018-01-02 12:37 GMT-03:00 Christof Ressi :
>>
>> what do you mean by [declare cyclone]?
>>
>> in case you mean [declare -stdpath cyclone]:
>
>
> I meant adding a library as path or a lib, either in -stdpath / -path /
> -stdlib / -lib  (is there a difference in behaviour between them?)
>
>>
>> a) this would only work if cyclone is in the user's stdpath (which you
>> can't know as a library writer)
>
>
> why?
>
>>
>> b) it only adds the cyclone folder to the search path. writing [gate] is a
>> gamble because iemlib could be earlier in the search path (or the single
>> binary library could've been loaded).
>>
>>
>> Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
>> Von: "Alexandre Torres Porres" 
>> An: "Christof Ressi" 
>> Cc: "João Pais" , pd-l...@mail.iem.at
>> Betreff: Re: [PD] declare vs. namespaces - current best practice
>>
>> questions
>>
>> 2018-01-02 8:02 GMT-03:00 Christof Ressi
>> :Hi, I think in your
>> case you shouldn't need [declare] at all. [declare -stdlib somelib] makes
>> the assumption that 'somelib' is installed in one of Pd's standard paths.
>> This was maybe true for Pd extended where all libraries were in the /extra
>> folder but actually it could be any other folder (which the user added to
>> their search paths).
>>
>> IMHO, best practice is to explicitly list your dependencies and have the
>> user set them up correctly.
>>
>> regarding namespaces:
>>
>> In an abstraction library I would always use them if I can (unfortunately
>> it's not possible with externals which are part of a single binary
>> library). It eliminates the possibility that a wrong abstraction/external
>> is called. My favourite example:
>> Say that for some weird reason you're using [gate] from cyclone. If a
>> users happens to have iemlib earlier in their search path, all your
>> abstractions will have iemlib's [gate] object instead - which works
>> exactly the other way around! This actually happened to a friend of mine
>> :-D.
>>
>> won't [declare cyclone] force a priority of it over iemlib? If not,
>> shouldn't it?
>>
>> now, for related discussions on declare/standard paths,
>> see 
>> https://github.com/pure-data/pure-data/pull/205[https://github.com/pure-data/pure-data/pull/205]
>> & 
>> https://github.com/pure-data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
>>
>> cheers,
>> happy 2018

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

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

> (is there a difference in behaviour between them?)

 

stdlib is relative to the 'standard paths' whereas path is relative to the current patch.

 

my point is that the user could have their libraries in a totally different place so that none of [declare -path/-stdpath/-lib/-stdlib cyclone] will work.

 

Gesendet: Donnerstag, 04. Januar 2018 um 22:14 Uhr
Von: "Alexandre Torres Porres" 
An: "Christof Ressi" 
Cc: pd-l...@mail.iem.at
Betreff: Re: Re: [PD] declare vs. namespaces - current best practice


 
 
2018-01-02 12:37 GMT-03:00 Christof Ressi :

what do you mean by [declare cyclone]?

in case you mean [declare -stdpath cyclone]:

 

I meant adding a library as path or a lib, either in -stdpath / -path / -stdlib / -lib  (is there a difference in behaviour between them?)

 

a) this would only work if cyclone is in the user's stdpath (which you can't know as a library writer)

 

why?

 

b) it only adds the cyclone folder to the search path. writing [gate] is a gamble because iemlib could be earlier in the search path (or the single binary library could've been loaded).
 

Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
Von: "Alexandre Torres Porres" 
An: "Christof Ressi" 
Cc: "João Pais" , pd-l...@mail.iem.at
Betreff: Re: [PD] declare vs. namespaces - current best practice

questions
 
2018-01-02 8:02 GMT-03:00 Christof Ressi :Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).

IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.

regarding namespaces:

In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example:
Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D.
 
won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't it?
 
now, for related discussions on declare/standard paths, see https://github.com/pure-data/pure-data/pull/205[https://github.com/pure-data/pure-data/pull/205] & https://github.com/pure-data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
 
cheers,
happy 2018








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

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-02 12:37 GMT-03:00 Christof Ressi :

> what do you mean by [declare cyclone]?
>
> in case you mean [declare -stdpath cyclone]:
>

I meant adding a library as path or a lib, either in -stdpath / -path /
-stdlib / -lib  (is there a difference in behaviour between them?)


> a) this would only work if cyclone is in the user's stdpath (which you
> can't know as a library writer)
>

why?


> b) it only adds the cyclone folder to the search path. writing [gate] is a
> gamble because iemlib could be earlier in the search path (or the single
> binary library could've been loaded).
>
>
> Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
> Von: "Alexandre Torres Porres" 
> An: "Christof Ressi" 
> Cc: "João Pais" , pd-l...@mail.iem.at
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> questions
>
> 2018-01-02 8:02 GMT-03:00 Christof Ressi  christof.re...@gmx.at]>:Hi, I think in your case you shouldn't need
> [declare] at all. [declare -stdlib somelib] makes the assumption that
> 'somelib' is installed in one of Pd's standard paths. This was maybe true
> for Pd extended where all libraries were in the /extra folder but actually
> it could be any other folder (which the user added to their search paths).
>
> IMHO, best practice is to explicitly list your dependencies and have the
> user set them up correctly.
>
> regarding namespaces:
>
> In an abstraction library I would always use them if I can (unfortunately
> it's not possible with externals which are part of a single binary
> library). It eliminates the possibility that a wrong abstraction/external
> is called. My favourite example:
> Say that for some weird reason you're using [gate] from cyclone. If a
> users happens to have iemlib earlier in their search path, all your
> abstractions will have iemlib's [gate] object instead - which works exactly
> the other way around! This actually happened to a friend of mine :-D.
>
> won't [declare cyclone] force a priority of it over iemlib? If not,
> shouldn't it?
>
> now, for related discussions on declare/standard paths, see
> https://github.com/pure-data/pure-data/pull/205[https:
> //github.com/pure-data/pure-data/pull/205] & https://github.com/pure-
> data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
>
> cheers,
> happy 2018
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] NIME 2018 2nd call for submissions

[Ivica Ico Bukvic]

NIME 2018 Call for submissions
Please pardon the cross-posting,

*A friendly reminder of the upcoming submission deadline January 20th, 
2018, for the NIME 2018 international conference. The paper templates 
and all other supporting information is available on the website 
(**NIME2018.ORG ). We sincerely look forward to 
your submissions. In the meantime, should you have any questions, please 
do not hesitate to contact us. ***On behalf of the entire committee I 
wish you all a happy New Year.**



NIME (New Interfaces for Musical Expression) is the premier conference 
in human-machine interfaces and interactions for musical performance. 
NIME is a gathering of researchers, designers, musicians, who come 
together to share knowledge, perform music, and build community through 
research presentations, concerts, installations, and workshops.


On behalf of the 2018 NIME Committee I am pleased to announce that the 
NIME 2018 "Mirrored Resonances" Conference call for submissions is now 
officially open! Co-organized between Virginia Tech and the University 
of Virginia, the conference will take place June 3-6, 2018 in 
Blacksburg, Virginia. We welcome submissions of papers, posters, panels, 
musical performances, installations, demos, and workshops, particularly 
those that may respond to the overarching conference theme of “Mirrored 
Resonances” and its thematic areas in any of the many ways they might be 
interpreted. Likewise, we encourage potential participants to consider 
exploring the unique Virginia Tech facilities, including the Institute 
for Creativity, Arts, and Technology’s Cube with a massive high density 
loudspeaker array. The deadline for the *double-blind peer reviewed 
submissions*, including papers, panels, demo papers, music, and 
installations is January 20th, 2018. Submissions created by January 20th 
will continue to be editable until January 27th when the submission 
process will close. Demos without paper and workshops will be *curated 
*and have an extended submission deadline until March 1st, 2018. In 
addition to the NIME and academic communities, we also invite industry, 
as well as non-academic creatives to consider participating in the 
aforesaid categories. For a complete list of important dates visit the 
Participate  page.


We are excited to announce that the conference will feature four keynote 
artists:


*Onyx Ashanti**
**Benjamin Knapp**
**Ikue Mori**
**Pamela Z*


If interested in sponsorship opportunities please do not hesitate to 
contact us 




On behalf of the entire NIME 2018 Committee, we look forward to 
welcoming you in Virginia next June!


Go to the website 



NIME2018.ORG 
Facebook  
Twitter  
Instagram  
Website 


Moss Arts Center
190 Alumni Mall
Blacksburg, VA 24060
Like 
Tweet 
Share 
Forward 
 



___
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

Re: [PD] declare vs. namespaces - current best practice

[tim vets]

On Jan 3, 2018 10:24 PM, "Derek Kwan"  wrote:

"Christof Ressi"  writes:

>> and usually involves sort of prefixing or suffixing for every
>> abstraction/external.
>
> I've also done this in the past.
> namespacing by prepending the folder name has one advantage, though:
> it provides you the possibility to choose between the long (safe) and
> short (unsafe) name. short names are convenient in rapid prototyping
> while long names are preferable if things ought to be robust.
>
> but after all, it's a matter of taste I guess.
>

Interesting. I suppose this makes me think about more robust and defined
examples of namespacing. Taking python for instance where you can import
modules with shorter names with something like "import numpy as np" so
you can just type "np.array" instead of "numpy.array" each time or you
have the option to dump everything into the  global namespace which is
similar to the situation we have currently of just importing the path or
compiled library wholesale through "from numpy import *".

I'd imagine that implementing a system like this in Pd would be very^999 far
from trivial to implement, cause more confusion to the general end-user
than it's worth it just because users like me don't want to type
[cyclone/*] out every time (and there is already enough confusion about
not being able to instantiate anything in Gem/zexy/cyclone/etc.  even though
they've already installed them onto their computers), and probably break
everything which would be a huge no-no. but it is
interesting to think about =P.

Derek


maybe I'm stretching the topic here, but, how about tab-completion?


--
Derek Kwan
www.derekxkwan.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