Re: [PD] purr data beta1

[Alexandre Torres Porres]

2016-09-29 23:35 GMT-03:00 Dan Wilcox :

> But most of all, nobody stepped up to keep it going. There was plenty of
> wringing of hands but no real effort in the end. I considered it, but I
> much prefer the new approach of decentralized, easy to build externals and
> a more robust vanilla, as opposed to me becoming the “extended guy”.
>

Well, one good thing to point is that Pd-L2ork (and its Purr Data branch)
started as a fork from Extended (from 0.42-5 may I guess?). So it's not
like it died for nothing and, in a sense, Purr Data still keeps it going.

And I have to agree that good stuff came out of it when it was possible to
focus attention into vanilla, to make it more robust, and the efforts on
pd-lib-builder/deken to make it easier to build and install externals.

In fact, for me, the biggest deal in extended was all the extended
libraries, but most of them were just abandoned... what good is that? Where
I'm getting at is that one way to get involved and help in the "expanded Pd
flavours" could be taking care of libraries. Like updating cyclone objects
to max 7 :)

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

[PD] iemguts outdated on Deken

[Liam Goodacre]

Last time I checked, Deken had an outdated version of iemguts. Since iemguts 
now includes [initbang], it would be nice if this were made available to 
Vanilla users without having to manually download and install. Is it possible 
to update Deken to the latest version from the git?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Dan Wilcox]

> From: Alexandre Torres Porres >
> 
> I have the idea that extended's development was highly centralized, not that 
> I mean to imply that this was the intention, but it seems to me that's how it 
> went, so when it was abandoned, it was hard to take it further - I might be 
> totally wrong in my analysis so please feel free to correct me.

It was the fact that extended:

1. largely relied on the efforts of 1 person
2. was hard to build, as Jonathan mentioned
3. was largely centralized (not a huge deal as anyone could get SVN access if 
they really wanted it)
4. largely diverged from Pd vanilla to the point where it would be pretty 
difficult to integrate new versions of vanilla, especially if you are not “the 
1 person” with the knowledge

But most of all, nobody stepped up to keep it going. There was plenty of 
wringing of hands but no real effort in the end. I considered it, but I much 
prefer the new approach of decentralized, easy to build externals and a more 
robust vanilla, as opposed to me becoming the “extended guy”.

> What I wanna say is that I just hope more people get involved and collaborate 
> with Purr Data and Pd-L2ork, so it benefits from an actual community effort 
> where development happens faster.

Sure. I would point out that this was the intent of Pd-extended as well. I hope 
that Purr Data will find a way to overcome extended problems 1 & 4, if it 
hasn’t already.


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

Re: [PD] purr data beta1

[Dan Wilcox]

> On Sep 29, 2016, at 6:32 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Jonathan Wilkes >
> Subject: Re: [PD] purr data beta1
> Date: September 29, 2016 at 4:24:02 PM MDT
> To: hi >
> Cc: Pd-List >
> Reply-To: Jonathan Wilkes >
> 
> 
> > oh, unfortunately I cant run the OSX version on 10.8.5. It says it requires 
> > 10.9. 
> 
> I'm building on an x86_64 machine that's running 10.11.6.  Is it possible to 
> target 10.8.5 with Apple's tools on my machine?

Set a lower minimum OS X deployment target via -mmacosx-version-min. Example: 
https://github.com/pure-data/pure-data/blob/autotools_updates/configure.ac#L55 


I think, by default, if you do not set a min target it’s set to the current SDK 
you use when building.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 


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

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

Once the script has done it's job, I can find all the compiled stuff in 


packages/build/usr/local, so now I want a clean install/uninstall of all 
the stuff
in my system so I'm doing 'make install' from package directory, but it 
compiles again, is it the good way to go?
You should have a tar.gz in the parent directory of the root repo 
directory.  Untar it, enter the directory it creates, then do `make install` 
there.

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

Re: [PD] purr data beta1

[patrice colet]

Le 30/09/2016 à 03:01, Jonathan Wilkes a écrit :

> I'm a bit confused because I haven't found the tar_em_up.sh goodie in


the script folder from your git repository.

It's in l2ork_addons.  (Would be nice to have it toplevel and flatten 
the whole
complicated repo layout, but with a multi-level recursive gnu makefile 
build

system that's unfortunately very difficult)

It's allright, I was just too lazy to look deeper and find the script, a 
note about this in README.md would help a lot I guess...


Once the script has done it's job, I can find all the compiled stuff in 
packages/build/usr/local, so now I want a clean install/uninstall of all 
the stuff
in my system so I'm doing 'make install' from package directory, but it 
compiles again, is it the good way to go?
<>___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

> I'm a bit confused because I haven't found the tar_em_up.sh goodie in 


the script folder from your git repository.
It's in l2ork_addons.  (Would be nice to have it toplevel and flatten the whole 
complicated repo layout, but with a multi-level recursive gnu makefile build 
system that's unfortunately very difficult)

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

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

> I have the idea that extended's development was highly centralized, not that 
> I mean to imply that this was the intention, but it seems to me that's how it 
> went, so when it was abandoned, it was hard to take it further - I might be 
> totally wrong in my analysis so please feel free to correct me.


The main problem was that setting up a build environment was way too 
complicated.  Also, the build itself takes too long, and there aren't adequate 
tests to ensure the build completed properly.

I've improved the Windows build environment immensely just by leveraging 
msys2.  But the new msys2 installer has a bug that requires an obscure 
workaround.  Apparently the msys2 team already fixed the bug.  But the 
lead dev is on vacation for two weeks, and guess who is the only person 
able to push bug fixes into the installer binaries...
So apparently the free software ecosystem is full of problems like this.
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

>> The good news is it won't crash.  The bad news is that so far I've had 


>> to compile
>> without jack support to get things to build correctly.
> That's quite a bad a new indeed, but anyway I haven't found a way to 
> compile because all the GNU/linux stuff I've found in there are Debian only,
> and I'm not on Debian, otherwise I'd just use binaries.
I'll look into building with Jack support for the next release on OSX.
The easy, documented, tested, and currently maintained "stuff" is 
for building deb packages.  You could try `tar_em_up.sh -F` which-- 
if successful-- will output a tar.gz in the parent dir of the main repo 
dir. Or if you don't need Gem you can do `tar_em_up.sh -f` for a 
much faster compilation time.

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

Re: [PD] purr data beta1

[Alexandre Torres Porres]

2016-09-29 19:00 GMT-03:00 patrice colet :

>
> Le 29/09/2016 à 23:40, IOhannes m zmölnig a écrit :
>
>> On 09/29/2016 11:23 PM, patrice colet wrote:
>>
>>> Not sure Purr Data will replace anything since sources aren't available
>>>
>> how come? https://git.purrdata.net/jwilkes/purr-data
>>
>
> I didn't know about this link, thanks for posting it
>

Well, not only the source is available, but as I understand it, both Purr
Data and Pd-L2ork are open to collaboration by anyone who wishes to join
forces.

I have the idea that extended's development was highly centralized, not
that I mean to imply that this was the intention, but it seems to me that's
how it went, so when it was abandoned, it was hard to take it further - I
might be totally wrong in my analysis so please feel free to correct me.

What I wanna say is that I just hope more people get involved and
collaborate with Purr Data and Pd-L2ork, so it benefits from an actual
community effort where development happens faster.

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

[PD] Request: [random 0] returns floats

[William Huston]

Currently, [random 0] returns 0 when banged.

Does anyone actually use this behavior?

(I could imagine a case where new values are sent to the range inlet, and
you might want this for consistency).

I would love to have a way to random floats between 0-1 in a native
function in Vanilla, since these are easier to scale.

Yes, it's easy enough to get this by picking some large number N:

[random N]
|
[/ N]

Still it would be nice to have natively.

Thanks.

-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

> oh, unfortunately I cant run the OSX version on 10.8.5. It says it requires 
> 10.9. 



I'm building on an x86_64 machine that's running 10.11.6.  Is it possible to 
target 10.8.5 with Apple's tools on my machine?

> just as report,

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

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

Le 29/09/2016 à 23:45, Jonathan Wilkes a écrit :


>> > Not sure Purr Data will replace anything since sources aren't available
>>
>> https://git.purrdata.net/jwilkes/purr-data
>>
>>
>>
>> Btw-- successfully building for Windows, OSX, and Gnu/Linux was by _far_
>> the most time-consuming part of this project.
>>

> I'm trying it right now with hoping that it won't crash when jackd is 
> stopped, that's the main reason for me to consume time on it.
The good news is it won't crash.  The bad news is that so far I've had to 
compile 
without jack support to get things to build correctly.
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[hi via Pd-list]

oh, unfortunately I cant run the OSX version on 10.8.5. It says it requires 
10.9. 

just as report,

Jonas


Am 29.09.2016 um 00:51 schrieb Jonathan Wilkes via Pd-list 
:

> This is the beta 1 release of Purr Data (the GUI port of Pd-l2ork)
> 
> Change log:
> * fix many errors in the GUI
> * fix position of popup menu when zooming
> * fix scalar crasher
> * fix gop display error
> * fix disappearing $@
> * save gui preset with preferences
> * fix segfault with preference changes
> * fixed many memory leaks with patches backported from Pd Vanilla
> * small fixes to help patches
> * add text editor window for [text define]
> * add and improve the scalar properties dialog
> * add default float arg for Pd's "quit" message (good for test patches)
> * updated some external libraries
> 
> This is a beta release, so please report lots of bugs to
> https://git.purrdata.net/jwilkes/purr-data/issues
> 
> Binaries here:
> https://git.purrdata.net/jwilkes/purr-data-binaries/tree/master
> 
> -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] purr data beta1

[patrice colet]

Le 29/09/2016 à 23:45, Jonathan Wilkes a écrit :

> Not sure Purr Data will replace anything since sources aren't available

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



Btw-- successfully building for Windows, OSX, and Gnu/Linux was by _far_
the most time-consuming part of this project.



I'm trying it right now with hoping that it won't crash when jackd is 
stopped, that's the main reason for me to consume time on it.
<>___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[patrice colet]

Le 29/09/2016 à 23:40, IOhannes m zmölnig a écrit :

On 09/29/2016 11:23 PM, patrice colet wrote:

Not sure Purr Data will replace anything since sources aren't available

how come? https://git.purrdata.net/jwilkes/purr-data


I didn't know about this link, thanks for posting it
<>___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] switch~

[Jeppi Jeppi]

Hi all,

I noticed that having [switch~ 0] within abstractions like [pd module1] and so 
on, do not seem to save their DSP resources as expected.

Is it something wrong?


Thanks in advance,

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

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

> Not sure Purr Data will replace anything since sources aren't available
https://git.purrdata.net/jwilkes/purr-data


Btw-- successfully building for Windows, OSX, and Gnu/Linux was by _far_ 
the most time-consuming part of this project. 
-Jonathan

Le 29/09/2016 à 23:14, Alexandre Torres Porres a écrit :
> what is not clear to me is if Purr Data will replace Pd-L2ork
>
> so we could also say "Purr Data is the new Pd-L2ork"
>
> 2016-09-29 18:12 GMT-03:00 Alexandre Torres Porres  >:
>
>    Well, for one, I've been saying around: "Purr Data is the New
>    Extended"...
>
>    2016-09-29 16:34 GMT-03:00 Giulio Moro via Pd-list
>    >:
>
>        interesting, can you please elaborate on  this:
>
>
>        > Its design principle is centered around nimble distributed
>        development which may (and already does) include improvements
>        in core behavior.
>
>        thanks
>        Giulio
>        >
>        > From: Ivica Bukvic >
>        >To: Dan Wilcox         >
>        >Cc: Pd-list >
>        >Sent: Thursday, 29 September 2016, 20:28
>        >Subject: Re: [PD] purr data beta1
>        >
>        >
>        >
>        >I think it can only be spiritual successor if you believe it
>        to be one in part because its philosophy is different. What I
>        said originally was that I had no explicit intentions on
>        replacing extended in part because I was not sure what was its
>        roadmap and whether it had a chance of being developed
>        further. In other words, I never denied its capacity to
>        replace extended but also did not want to assert that in any
>        kind of authoritative way. Hope this helps!
>        >--
>        >Ivica Ico Bukvic, D.M.A.
>        >Associate Professor
>        >Computer Music
>        >ICAT Senior Fellow
>        >Director -- DISIS, L2Ork
>        >Virginia Tech
>        >School of Performing Arts – 0141
>        >Blacksburg, VA 24061
>        >(540) 231-6139
>        >i...@vt.edu 
>        >www.performingarts.vt.edu 
>        >disis.icat.vt.edu 
>        >l2ork.icat.vt.edu 
>        >ico.bukvic.net 
>        >
>        >
>        >On Sep 29, 2016 14:52, "Dan Wilcox"         > wrote:
>        >
>        >In this light, is Purr Data the spiritual successor for
>        Pd-Extended? As I recall in previous discussions, y'all were
>        explicit that Pd-L2Ork was not.
>        >>
>        >>
>        >>This question is not meant as a slight in any way. I’m just
>        curious how this new project fits within your goals and the Pd
>        community at large.
>        >>
>        >>
>        >>
>        >>
>        >>Dan Wilcox
>        >>@danomatika
>        >>danomatika.com 
>        >>
>        >>robotcowboy.com 
>        >>
>        >>On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at
>         wrote:
>        >>>
>        >>>From: Alexandre Torres Porres         >
>        >>>
>        >>>Subject: Re: [PD] purr data beta1
>        >>>
>        >>>Date: September 29, 2016 at 11:21:49 AM MDT
>        >>>
>        >>>To: "pd-list@lists.iem.at "
>        >
>        >>>
>        >>>
>        >>>
>        >>>
>        >>>In short: A Game Changer!
>        >>>
>        >>>
>        >>>2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic         >:
>        >>>
>        >>>Purr-Data is a GUI rewrite for Pd-L2Ork which has over
>        1,500 patches/bugfixes/improvements over vanilla/extended. Its
>        design principle is centered around nimble distributed
>        development which may (and already does) include improvements
>        in core behavior. Hope this helps!
>        
>        Best,
>        Ico
>        >>
>        >
>        >___
>        >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 beta1

[IOhannes m zmölnig]

On 09/29/2016 11:23 PM, patrice colet wrote:
> Not sure Purr Data will replace anything since sources aren't available

how come? https://git.purrdata.net/jwilkes/purr-data

gmdsar
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] purr data beta1

[Jonathan Wilkes via Pd-list]

> what is not clear to me is if Purr Data will replace Pd-L2ork


I'm still missing some GUI externals, Ivica's K12 mode, and a few 
Pd-l2ork-specific externals that require work to get running under 
Windows.

Also, the HTML5 interface is a real cpu hog.  If it's a single core 
machine you'll see a big performance hit.  It's getting better with 
each release of nw.js, and I really haven't done a single thing to 
optimize anything yet.
-Jonathan
 
> so we could also say "Purr Data is the new Pd-L2ork"
2016-09-29 18:12 GMT-03:00 Alexandre Torres Porres :

Well, for one, I've been saying around: "Purr Data is the New Extended"...
2016-09-29 16:34 GMT-03:00 Giulio Moro via Pd-list :

interesting, can you please elaborate on  this:


> Its design principle is centered around nimble distributed development which 
> may (and already does) include improvements in core behavior.

thanks
Giulio
>_ ___
> From: Ivica Bukvic 
>To: Dan Wilcox 
>Cc: Pd-list 
>Sent: Thursday, 29 September 2016, 20:28
>Subject: Re: [PD] purr data beta1
>
>
>
>I think it can only be spiritual successor if you believe it to be one in part 
>because its philosophy is different. What I said originally was that I had no 
>explicit intentions on replacing extended in part because I was not sure what 
>was its roadmap and whether it had a chance of being developed further. In 
>other words, I never denied its capacity to replace extended but also did not 
>want to assert that in any kind of authoritative way. Hope this helps!
>--
>Ivica Ico Bukvic, D.M.A.
>Associate Professor
>Computer Music
>ICAT Senior Fellow
>Director -- DISIS, L2Ork
>Virginia Tech
>School of Performing Arts – 0141
>Blacksburg, VA 24061
>(540) 231-6139
>i...@vt.edu
>www.performingarts.vt.edu
>disis.icat.vt.edu
>l2ork.icat.vt.edu
>ico.bukvic.net
>
>
>On Sep 29, 2016 14:52, "Dan Wilcox"  wrote:
>
>In this light, is Purr Data the spiritual successor for Pd-Extended? As I 
>recall in previous discussions, y'all were explicit that Pd-L2Ork was not.
>>
>>
>>This question is not meant as a slight in any way. I’m just curious how this 
>>new project fits within your goals and the Pd community at large.
>>
>>
>>
>>
>>Dan Wilcox
>>@danomatika
>>danomatika.com
>>
>>robotcowboy.com
>>
>>On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at wrote:
>>>
>>>From: Alexandre Torres Porres 
>>>
>>>Subject: Re: [PD] purr data beta1
>>>
>>>Date: September 29, 2016 at 11:21:49 AM MDT
>>>
>>>To: "pd-list@lists.iem.at" 
>>>
>>>
>>>
>>>
>>>In short: A Game Changer!
>>>
>>>
>>>2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic :
>>>
>>>Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500 
>>>patches/bugfixes/improvements over vanilla/extended. Its design principle is 
>>>centered around nimble distributed development which may (and already does) 
>>>include improvements in core behavior. Hope this helps!

Best,
Ico
>>
>
>_ __
>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/li 
stinfo/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] purr data beta1

[patrice colet]

Not sure Purr Data will replace anything since sources aren't available

Le 29/09/2016 à 23:14, Alexandre Torres Porres a écrit :

what is not clear to me is if Purr Data will replace Pd-L2ork

so we could also say "Purr Data is the new Pd-L2ork"

2016-09-29 18:12 GMT-03:00 Alexandre Torres Porres >:


Well, for one, I've been saying around: "Purr Data is the New
Extended"...

2016-09-29 16:34 GMT-03:00 Giulio Moro via Pd-list
>:

interesting, can you please elaborate on  this:


> Its design principle is centered around nimble distributed
development which may (and already does) include improvements
in core behavior.

thanks
Giulio
>
> From: Ivica Bukvic >
>To: Dan Wilcox >
>Cc: Pd-list >
>Sent: Thursday, 29 September 2016, 20:28
>Subject: Re: [PD] purr data beta1
>
>
>
>I think it can only be spiritual successor if you believe it
to be one in part because its philosophy is different. What I
said originally was that I had no explicit intentions on
replacing extended in part because I was not sure what was its
roadmap and whether it had a chance of being developed
further. In other words, I never denied its capacity to
replace extended but also did not want to assert that in any
kind of authoritative way. Hope this helps!
>--
>Ivica Ico Bukvic, D.M.A.
>Associate Professor
>Computer Music
>ICAT Senior Fellow
>Director -- DISIS, L2Ork
>Virginia Tech
>School of Performing Arts – 0141
>Blacksburg, VA 24061
>(540) 231-6139
>i...@vt.edu 
>www.performingarts.vt.edu 
>disis.icat.vt.edu 
>l2ork.icat.vt.edu 
>ico.bukvic.net 
>
>
>On Sep 29, 2016 14:52, "Dan Wilcox" > wrote:
>
>In this light, is Purr Data the spiritual successor for
Pd-Extended? As I recall in previous discussions, y'all were
explicit that Pd-L2Ork was not.
>>
>>
>>This question is not meant as a slight in any way. I’m just
curious how this new project fits within your goals and the Pd
community at large.
>>
>>
>>
>>
>>Dan Wilcox
>>@danomatika
>>danomatika.com 
>>
>>robotcowboy.com 
>>
>>On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at
 wrote:
>>>
>>>From: Alexandre Torres Porres >
>>>
>>>Subject: Re: [PD] purr data beta1
>>>
>>>Date: September 29, 2016 at 11:21:49 AM MDT
>>>
>>>To: "pd-list@lists.iem.at "
>
>>>
>>>
>>>
>>>
>>>In short: A Game Changer!
>>>
>>>
>>>2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic >:
>>>
>>>Purr-Data is a GUI rewrite for Pd-L2Ork which has over
1,500 patches/bugfixes/improvements over vanilla/extended. Its
design principle is centered around nimble distributed
development which may (and already does) include improvements
in core behavior. Hope this helps!

Best,
Ico
>>
>
>___
>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 -> 

Re: [PD] purr data beta1

[Alexandre Torres Porres]

what is not clear to me is if Purr Data will replace Pd-L2ork

so we could also say "Purr Data is the new Pd-L2ork"

2016-09-29 18:12 GMT-03:00 Alexandre Torres Porres :

> Well, for one, I've been saying around: "Purr Data is the New Extended"...
>
> 2016-09-29 16:34 GMT-03:00 Giulio Moro via Pd-list :
>
>> interesting, can you please elaborate on  this:
>>
>>
>> > Its design principle is centered around nimble distributed development
>> which may (and already does) include improvements in core behavior.
>>
>> thanks
>> Giulio
>> >
>> > From: Ivica Bukvic 
>> >To: Dan Wilcox 
>> >Cc: Pd-list 
>> >Sent: Thursday, 29 September 2016, 20:28
>> >Subject: Re: [PD] purr data beta1
>> >
>> >
>> >
>> >I think it can only be spiritual successor if you believe it to be one
>> in part because its philosophy is different. What I said originally was
>> that I had no explicit intentions on replacing extended in part because I
>> was not sure what was its roadmap and whether it had a chance of being
>> developed further. In other words, I never denied its capacity to replace
>> extended but also did not want to assert that in any kind of authoritative
>> way. Hope this helps!
>> >--
>> >Ivica Ico Bukvic, D.M.A.
>> >Associate Professor
>> >Computer Music
>> >ICAT Senior Fellow
>> >Director -- DISIS, L2Ork
>> >Virginia Tech
>> >School of Performing Arts – 0141
>> >Blacksburg, VA 24061
>> >(540) 231-6139
>> >i...@vt.edu
>> >www.performingarts.vt.edu
>> >disis.icat.vt.edu
>> >l2ork.icat.vt.edu
>> >ico.bukvic.net
>> >
>> >
>> >On Sep 29, 2016 14:52, "Dan Wilcox"  wrote:
>> >
>> >In this light, is Purr Data the spiritual successor for Pd-Extended? As
>> I recall in previous discussions, y'all were explicit that Pd-L2Ork was not.
>> >>
>> >>
>> >>This question is not meant as a slight in any way. I’m just curious how
>> this new project fits within your goals and the Pd community at large.
>> >>
>> >>
>> >>
>> >>
>> >>Dan Wilcox
>> >>@danomatika
>> >>danomatika.com
>> >>
>> >>robotcowboy.com
>> >>
>> >>On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at wrote:
>> >>>
>> >>>From: Alexandre Torres Porres 
>> >>>
>> >>>Subject: Re: [PD] purr data beta1
>> >>>
>> >>>Date: September 29, 2016 at 11:21:49 AM MDT
>> >>>
>> >>>To: "pd-list@lists.iem.at" 
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>In short: A Game Changer!
>> >>>
>> >>>
>> >>>2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic :
>> >>>
>> >>>Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500
>> patches/bugfixes/improvements over vanilla/extended. Its design principle
>> is centered around nimble distributed development which may (and already
>> does) include improvements in core behavior. Hope this helps!
>> 
>> Best,
>> Ico
>> >>
>> >
>> >___
>> >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/li
>> stinfo/pd-list
>>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Alexandre Torres Porres]

Well, for one, I've been saying around: "Purr Data is the New Extended"...

2016-09-29 16:34 GMT-03:00 Giulio Moro via Pd-list :

> interesting, can you please elaborate on  this:
>
>
> > Its design principle is centered around nimble distributed development
> which may (and already does) include improvements in core behavior.
>
> thanks
> Giulio
> >
> > From: Ivica Bukvic 
> >To: Dan Wilcox 
> >Cc: Pd-list 
> >Sent: Thursday, 29 September 2016, 20:28
> >Subject: Re: [PD] purr data beta1
> >
> >
> >
> >I think it can only be spiritual successor if you believe it to be one in
> part because its philosophy is different. What I said originally was that I
> had no explicit intentions on replacing extended in part because I was not
> sure what was its roadmap and whether it had a chance of being developed
> further. In other words, I never denied its capacity to replace extended
> but also did not want to assert that in any kind of authoritative way. Hope
> this helps!
> >--
> >Ivica Ico Bukvic, D.M.A.
> >Associate Professor
> >Computer Music
> >ICAT Senior Fellow
> >Director -- DISIS, L2Ork
> >Virginia Tech
> >School of Performing Arts – 0141
> >Blacksburg, VA 24061
> >(540) 231-6139
> >i...@vt.edu
> >www.performingarts.vt.edu
> >disis.icat.vt.edu
> >l2ork.icat.vt.edu
> >ico.bukvic.net
> >
> >
> >On Sep 29, 2016 14:52, "Dan Wilcox"  wrote:
> >
> >In this light, is Purr Data the spiritual successor for Pd-Extended? As I
> recall in previous discussions, y'all were explicit that Pd-L2Ork was not.
> >>
> >>
> >>This question is not meant as a slight in any way. I’m just curious how
> this new project fits within your goals and the Pd community at large.
> >>
> >>
> >>
> >>
> >>Dan Wilcox
> >>@danomatika
> >>danomatika.com
> >>
> >>robotcowboy.com
> >>
> >>On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at wrote:
> >>>
> >>>From: Alexandre Torres Porres 
> >>>
> >>>Subject: Re: [PD] purr data beta1
> >>>
> >>>Date: September 29, 2016 at 11:21:49 AM MDT
> >>>
> >>>To: "pd-list@lists.iem.at" 
> >>>
> >>>
> >>>
> >>>
> >>>In short: A Game Changer!
> >>>
> >>>
> >>>2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic :
> >>>
> >>>Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500
> patches/bugfixes/improvements over vanilla/extended. Its design principle
> is centered around nimble distributed development which may (and already
> does) include improvements in core behavior. Hope this helps!
> 
> Best,
> Ico
> >>
> >
> >___
> >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 user in Montreal / performance announcement

[cyrille henry]

hello,


Nicolas and I (chdh) will perform in Montreal tomorrow :
https://easternbloc.ca/en/sight-sound-festival/performances-events

I'll be glad to meet any pd user there.

cheers
Cyrille


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

[PD] Pd Convention 2016 Dates and Schedule

[Jaime Oliver]

Hi all, 

Here are the dates and locations for the Convention:
http://www.nyu-waverlylabs.org/pdcon16/schedule/ 


All the best,

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

Re: [PD] purr data beta1

[Giulio Moro via Pd-list]

interesting, can you please elaborate on  this:


> Its design principle is centered around nimble distributed development which 
> may (and already does) include improvements in core behavior. 

thanks
Giulio
>
> From: Ivica Bukvic 
>To: Dan Wilcox  
>Cc: Pd-list 
>Sent: Thursday, 29 September 2016, 20:28
>Subject: Re: [PD] purr data beta1
> 
>
>
>I think it can only be spiritual successor if you believe it to be one in part 
>because its philosophy is different. What I said originally was that I had no 
>explicit intentions on replacing extended in part because I was not sure what 
>was its roadmap and whether it had a chance of being developed further. In 
>other words, I never denied its capacity to replace extended but also did not 
>want to assert that in any kind of authoritative way. Hope this helps!
>-- 
>Ivica Ico Bukvic, D.M.A.
>Associate Professor
>Computer Music
>ICAT Senior Fellow
>Director -- DISIS, L2Ork
>Virginia Tech
>School of Performing Arts – 0141
>Blacksburg, VA 24061
>(540) 231-6139
>i...@vt.edu
>www.performingarts.vt.edu
>disis.icat.vt.edu
>l2ork.icat.vt.edu
>ico.bukvic.net
>
>
>On Sep 29, 2016 14:52, "Dan Wilcox"  wrote:
>
>In this light, is Purr Data the spiritual successor for Pd-Extended? As I 
>recall in previous discussions, y'all were explicit that Pd-L2Ork was not.
>>
>>
>>This question is not meant as a slight in any way. I’m just curious how this 
>>new project fits within your goals and the Pd community at large.
>>
>>
>>
>>
>>Dan Wilcox
>>@danomatika
>>danomatika.com
>>
>>robotcowboy.com
>>
>>On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at wrote:
>>>
>>>From: Alexandre Torres Porres 
>>>
>>>Subject: Re: [PD] purr data beta1
>>>
>>>Date: September 29, 2016 at 11:21:49 AM MDT
>>>
>>>To: "pd-list@lists.iem.at" 
>>>
>>>
>>>
>>>
>>>In short: A Game Changer!
>>>
>>>
>>>2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic :
>>>
>>>Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500 
>>>patches/bugfixes/improvements over vanilla/extended. Its design principle is 
>>>centered around nimble distributed development which may (and already does) 
>>>include improvements in core behavior. Hope this helps!

Best,
Ico
>>
>
>___
>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 beta1

[Ivica Bukvic]

I think it can only be spiritual successor if you believe it to be one in
part because its philosophy is different. What I said originally was that I
had no explicit intentions on replacing extended in part because I was not
sure what was its roadmap and whether it had a chance of being developed
further. In other words, I never denied its capacity to replace extended
but also did not want to assert that in any kind of authoritative way. Hope
this helps!

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sep 29, 2016 14:52, "Dan Wilcox"  wrote:

In this light, is Purr Data the spiritual successor for Pd-Extended? As I
recall in previous discussions, y'all were explicit that Pd-L2Ork was not.

This question is not meant as a slight in any way. I’m just curious how
this new project fits within your goals and the Pd community at large.


Dan Wilcox
@danomatika 
danomatika.com
robotcowboy.com

On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at wrote:

*From: *Alexandre Torres Porres 
*Subject: **Re: [PD] purr data beta1*
*Date: *September 29, 2016 at 11:21:49 AM MDT
*To: *"pd-list@lists.iem.at" 


In short: *A Game Changer!*

2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic :

> Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500
> patches/bugfixes/improvements over vanilla/extended. Its design principle
> is centered around nimble distributed development which may (and already
> does) include improvements in core behavior. Hope this helps!
>
> Best,
>
> Ico
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

> In this light, is Purr Data the spiritual successor for Pd-Extended?
Yes.

> As I recall in previous discussions, y'all were explicit that Pd-L2Ork was 
> not.
I don't remember that discussion.  But since Pd-l2ork only ever ran under 
GNU/Linux (and a very limited "demo" I wrote for OSX) I suppose it must 
have been mainly a theoretical discussion.
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Dan Wilcox]

In this light, is Purr Data the spiritual successor for Pd-Extended? As I 
recall in previous discussions, y'all were explicit that Pd-L2Ork was not.

This question is not meant as a slight in any way. I’m just curious how this 
new project fits within your goals and the Pd community at large.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Alexandre Torres Porres >
> Subject: Re: [PD] purr data beta1
> Date: September 29, 2016 at 11:21:49 AM MDT
> To: "pd-list@lists.iem.at " 
> >
> 
> 
> In short: A Game Changer!
> 
> 2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic  >:
> Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500 
> patches/bugfixes/improvements over vanilla/extended. Its design principle is 
> centered around nimble distributed development which may (and already does) 
> include improvements in core behavior. Hope this helps!
> 
> Best,
> 
> Ico
> 

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

Re: [PD] PdCon16~ results

[Dan Wilcox]

Thank you for in advance for organizing and hosting!

Happy to be part of the next Pd Con, one of the few places where everyon just 
“get’s it” :)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Sep 29, 2016, at 10:56 AM, Jaime Oliver  wrote:
> 
> Dear All, 
> 
> I just wanted to provide an update on PdCon results.
> 
> We have now sent notifications to all papers and performances and most 
> proposals. The submissions that haven’t received an official reply are larger 
> installations as we are still securing an appropriate space to host them. We 
> will however be in touch shortly about them.
> 
> If you have not received any communication about a paper, performance, or 
> workshop, please check your junk mailbox, and/or check your Easychair account 
> to make sure that the email specified there is the email account you’re 
> checking. 
> 
> Thank you for your patience!
> 
> All the best,
> 
> PdCon16
> 

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

Re: [PD] purr data beta1

[Alexandre Torres Porres]

In short: *A Game Changer!*

2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic :

> Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500
> patches/bugfixes/improvements over vanilla/extended. Its design principle
> is centered around nimble distributed development which may (and already
> does) include improvements in core behavior. Hope this helps!
>
> Best,
>
> Ico
>
> On 9/29/2016 10:48 AM, Giulio Moro via Pd-list wrote:
>
> Jonathan,
> I struggle a bit to understand what is the end goal of Purr Data:
> as far as I can tell, right now it is a re-implementation of the existing
> GUI in HTML5, which is great.
> Once this process is done (and I see we are very close now), how do you
> see the project will evolve? Will it just be about making the GUI more
> portable/customizable or do you foresee changes in the GUI/dsp
> communication protocol as well?
>
> Best,
> Giulio
>
>
> --
> *From:* Alexandre Torres Porres  
> *To:* Jonathan Wilkes  
> *Cc:* Pd-List  
> *Sent:* Thursday, 29 September 2016, 7:12
> *Subject:* Re: [PD] purr data beta1
>
> awesome, more and more excited at each new development step
>
> so, Scope~ is already ported, but [comment]  is not working yet, are you
> dealing with it?
>
> cheers
>
> 2016-09-29 1:51 GMT-03:00 Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at>:
>
> This is the beta 1 release of Purr Data (the GUI port of Pd-l2ork)
>
> Change log:
> * fix many errors in the GUI
> * fix position of popup menu when zooming
> * fix scalar crasher
> * fix gop display error
> * fix disappearing $@
> * save gui preset with preferences
> * fix segfault with preference changes
> * fixed many memory leaks with patches backported from Pd Vanilla
> * small fixes to help patches
> * add text editor window for [text define]
> * add and improve the scalar properties dialog
> * add default float arg for Pd's "quit" message (good for test patches)
> * updated some external libraries
>
> This is a beta release, so please report lots of bugs to
> https://git.purrdata.net/ jwilkes/purr-data/issues
> 
>
> Binaries here:
> https://git.purrdata.net/ jwilkes/purr-data-binaries/ tree/master
> 
>
> -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-l...@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] PdCon16~ results

[Jaime Oliver]

Hi all, 

The convention will start on the 16th win the afternoon. I realize the poster 
still says 17th; we’ll change it ASAP. Later today we’ll publish the dates and 
locations of all events.

best,

Jaime



> On Sep 29, 2016, at 1:18 PM, Alexandre Torres Porres  wrote:
> 
> howdy, does it start on the 16th or 17th, seems there are conflicting 
> infrmation about this
> 
> cheers
> 
> 2016-09-29 13:56 GMT-03:00 Jaime Oliver  >:
> Dear All,
> 
> I just wanted to provide an update on PdCon results.
> 
> We have now sent notifications to all papers and performances and most 
> proposals. The submissions that haven’t received an official reply are larger 
> installations as we are still securing an appropriate space to host them. We 
> will however be in touch shortly about them.
> 
> If you have not received any communication about a paper, performance, or 
> workshop, please check your junk mailbox, and/or check your Easychair account 
> to make sure that the email specified there is the email account you’re 
> checking.
> 
> Thank you for your patience!
> 
> All the best,
> 
> PdCon16
> ___
> 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] PdCon16~ results

[Alexandre Torres Porres]

howdy, does it start on the 16th or 17th, seems there are conflicting
infrmation about this

cheers

2016-09-29 13:56 GMT-03:00 Jaime Oliver :

> Dear All,
>
> I just wanted to provide an update on PdCon results.
>
> We have now sent notifications to all papers and performances and most
> proposals. The submissions that haven’t received an official reply are
> larger installations as we are still securing an appropriate space to host
> them. We will however be in touch shortly about them.
>
> If you have not received any communication about a paper, performance, or
> workshop, please check your junk mailbox, and/or check your Easychair
> account to make sure that the email specified there is the email account
> you’re checking.
>
> Thank you for your patience!
>
> All the best,
>
> PdCon16
> ___
> 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] PdCon16~ results

[Jaime Oliver]

Dear All, 

I just wanted to provide an update on PdCon results.

We have now sent notifications to all papers and performances and most 
proposals. The submissions that haven’t received an official reply are larger 
installations as we are still securing an appropriate space to host them. We 
will however be in touch shortly about them.

If you have not received any communication about a paper, performance, or 
workshop, please check your junk mailbox, and/or check your Easychair account 
to make sure that the email specified there is the email account you’re 
checking. 

Thank you for your patience!

All the best,

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

Re: [PD] purr data beta1

[Ivica Ico Bukvic]

Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500 
patches/bugfixes/improvements over vanilla/extended. Its design 
principle is centered around nimble distributed development which may 
(and already does) include improvements in core behavior. Hope this helps!


Best,

Ico


On 9/29/2016 10:48 AM, Giulio Moro via Pd-list wrote:

Jonathan,
I struggle a bit to understand what is the end goal of Purr Data:
as far as I can tell, right now it is a re-implementation of the 
existing GUI in HTML5, which is great.
Once this process is done (and I see we are very close now), how do 
you see the project will evolve? Will it just be about making the GUI 
more portable/customizable or do you foresee changes in the GUI/dsp 
communication protocol as well?


Best,
Giulio



*From:* Alexandre Torres Porres 
*To:* Jonathan Wilkes 
*Cc:* Pd-List 
*Sent:* Thursday, 29 September 2016, 7:12
*Subject:* Re: [PD] purr data beta1

awesome, more and more excited at each new development step

so, Scope~ is already ported, but [comment]  is not working yet,
are you dealing with it?

cheers

2016-09-29 1:51 GMT-03:00 Jonathan Wilkes via Pd-list
>:

This is the beta 1 release of Purr Data (the GUI port of Pd-l2ork)

Change log:
* fix many errors in the GUI
* fix position of popup menu when zooming
* fix scalar crasher
* fix gop display error
* fix disappearing $@
* save gui preset with preferences
* fix segfault with preference changes
* fixed many memory leaks with patches backported from Pd Vanilla
* small fixes to help patches
* add text editor window for [text define]
* add and improve the scalar properties dialog
* add default float arg for Pd's "quit" message (good for test
patches)
* updated some external libraries

This is a beta release, so please report lots of bugs to
https://git.purrdata.net/ jwilkes/purr-data/issues


Binaries here:
https://git.purrdata.net/ jwilkes/purr-data-binaries/
tree/master


-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

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

> Jonathan,

> I struggle a bit to understand what is the end goal of Purr Data:> as far as 
> I can tell, right now it is a re-implementation of the existing GUI 
> in HTML5, which is great.> Once this process is done (and I see we are very 
> close now), how do you see the > project will evolve? Will it just be about 
> making the GUI more 
> portable/customizable or do you foresee changes in the GUI/dsp 
> communication protocol as well?
It's essentially the development branch of Pd-l2ork, so it inherits all of 
its benefits-- infinite undo, native state-saving, GUI theming, and so on.
As for evolving-- you can have a look at the additions I've made to data 
structures to see.  With 15 objects one can make a scalar knob that rotates 
between 0 and 360 degrees.  With maybe 5-10 more objects one can have 
multiple knobs with changeable symbolic names.  Compare that to > 700 
lines of C code in the knob external (plus the occasional tcl error, "can't 
create" error, etc.)
 
There's another possibility which I haven't explored-- that is, you can load 
anything created with an HTML5 api into the Purr Data GUI and send messages 
to Pd from it.
 
As far as Pd<->GUI communication, I removed most of the tcl commands from 
the C code and replaced it with a parameterized interface.  I'm still 
leveraging 
the same socket-based communication.
-Jonathan

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

Re: [PD] purr data beta1

[Jonathan Wilkes via Pd-list]

> so, Scope~ is already ported, but [comment]  is not working yet, are you 
dealing with it?


Not yet.  For external GUI classes, I prioritized the necessary ones.  So I've 
ported pddplink/helplink/Scope~ and a few others because people were 
depending on them in help patches.
-Jonathan


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

Re: [PD] purr data beta1

[Giulio Moro via Pd-list]

Jonathan,I struggle a bit to understand what is the end goal of Purr Data:as 
far as I can tell, right now it is a re-implementation of the existing GUI in 
HTML5, which is great.Once this process is done (and I see we are very close 
now), how do you see the project will evolve? Will it just be about making the 
GUI more portable/customizable or do you foresee changes in the GUI/dsp 
communication protocol as well?
Best,Giulio

 
  From: Alexandre Torres Porres 
 To: Jonathan Wilkes  
Cc: Pd-List 
 Sent: Thursday, 29 September 2016, 7:12
 Subject: Re: [PD] purr data beta1
   
awesome, more and more excited at each new development step
so, Scope~ is already ported, but [comment]  is not working yet, are you 
dealing with it?
cheers
2016-09-29 1:51 GMT-03:00 Jonathan Wilkes via Pd-list :

This is the beta 1 release of Purr Data (the GUI port of Pd-l2ork)

Change log:
* fix many errors in the GUI
* fix position of popup menu when zooming
* fix scalar crasher
* fix gop display error
* fix disappearing $@
* save gui preset with preferences
* fix segfault with preference changes
* fixed many memory leaks with patches backported from Pd Vanilla
* small fixes to help patches
* add text editor window for [text define]
* add and improve the scalar properties dialog
* add default float arg for Pd's "quit" message (good for test patches)
* updated some external libraries

This is a beta release, so please report lots of bugs to
https://git.purrdata.net/ jwilkes/purr-data/issues

Binaries here:
https://git.purrdata.net/ jwilkes/purr-data-binaries/ tree/master
-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] Threading in Pd/libpd

[Giulio Moro via Pd-list]

>> With a 
>> threaded implementation, you could add a delay for that specific subpatch 
>> instead of the whole of Pd.
> I'm having trouble seeing how that would work in practice.
> Would the user specify the delay in ms/blocks as an argument?

Yes, that's the plan, by default I'd set it to the number of samples 
corresponding to the step determined by the specified overlap.

Giulio
>
> From: Jonathan Wilkes 
>To: Giulio Moro ; Pd-List  
>Sent: Thursday, 29 September 2016, 2:33
>Subject: Re: [PD] Threading in Pd/libpd
>
>> So having a look at the source code I'd say what would happen is that 
>
>> the second block prints the samples of the sound file.
>
>> I guess the point you are trying to make here is that a threaded version 
>
>> of [fft~], the perform routing should block if the samples are not ready in 
>
>> time. That sounds perfectly plausible (and doable) to me.
>> Or am I missing your point?
>
>That's right.  But on the broader scale I'm pointing out how easy it is to 
>overlook determinism in these cases.
>
>> I'd add that right now, if the system cannot compute an FFT on time and it 
>
>> causes dropouts, you have to solve that by increasing Pd's delay. With a 
>> threaded implementation, you could add a delay for that specific subpatch 
>> instead of the whole of Pd.
>
>I'm having trouble seeing how that would work in practice.  Would the 
>user specify the delay in ms/blocks as an argument?


>> Giulio
>
>
>
>>
>> From: Jonathan Wilkes 
>>To: Giulio Moro ; Pd-List  
>>Sent: Wednesday, 28 September 2016, 23:00
>>Subject: Re: [PD] Threading in Pd/libpd
>>
>>
>>
>>> Thanks Jonathan.
>>
>>
>>> Also [readsf~] supports threading and so do [udpsend] and [udpreceive], for 
>>> obvious reasons involving system calls.
>>
 Can you guarantee that the revisions you've implemented generate the same 
 output as Pd Vanilla, for all cases?
>>
>>
>>> I'd rather say it does not, in all cases. At the very least there is going 
>>> to be a delay involved. But, if this brings to a different behaviour, yet 
>>> still deterministic, would that be bad? After all, the above mentioned 
>>> objects are not deterministic themselves, yet they are widely used, with a 
>>> very high success rate.
>>
>>
>>udpsend and udpreceive are special cases because the protocol itself rules 
>>out the kind of determinism we're discussing. 
>>
>>
>>
>>So let's focus on readsf~ instead.
>>
>>
>>Suppose readsf~ is reading a sound file and outputs 3 blocks-- block 1, block 
>>2, and block 3.  The patch is outputting the sound file to the sound card, so 
>>we are 
>>
>>listening to the sound file as Pd is running.
>>
>>
>>Now, imagine this happens:
>>
>>
>>1st block: readsf~ perform routine finishes in time to output a block to the 
>>soundcard on schedule.
>>
>>2nd block: perform routine takes longer to compute, and it misses the 
>>deadline set for the next block to be delivered to the soundcard.  So we hear 
>>a dropout.
>>3rd block: perform routine finishes in time to meet the deadline.
>>
>>
>>Now, suppose we were debugging our patch by outputting each block of samples 
>>
>>to the console.  Here's the question, then: what gets printed for the 2nd 
>>block?  
>>
>>Does Pd print out the samples from the sound file that missed the deadline, 
>>or 
>>
>>does it print out 64 zeroes?
>>
>>
>>-Jonathan
>>
>>
>>
>>
>>
>>
>
>
>
>
>

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

Re: [PD] [PD-dev] Rewrite wrap~ to allow an extra block

[Ed Kelly via Pd-list]

Thanks Pierre. Trying it now.
This thing doesn't immediately crash or segfault, so I'm onto a winner 
eventually :)
I understand my brain is slightly more dead than it was. But we can move 
forward now.Cheers,Ed
 Lone Shark releases: Light Vessel Automatic available now on 12" vinyl.Build 
Your Wings on the Way Down, the new digital album available @ 
http://scifirecords.co.uk/releases 
Earthlings compilation is out now @ http://www.pyramidtransmissions.com

Ninja Jamm - the revolutionary music remix app for iOS and Android: 
http://www.ninjajamm.com/

Gemnotes-0.2: Live music notation for Pure Data, and Metastudio 5 live 
composition and improvisation suite, available at 
http://sharktracks.co.uk/puredata 

On Thursday, 29 September 2016, 12:27, Pierre Guillot 
 wrote:
 
 

 Hi Ed,The prototype of your perform method is wrong. You should have something 
like:static t_int *wrap_overshoot_tilde_perform( t_int *w){    
t_wrap_overshoot_tilde *x = (t_wrap_overshoot_tilde *)(w[1]);    t_sample *in  
= (t_sample *)(w[2]);    t_sample *out = (t_sample *)(w[3]);    t_int n       = 
(t_int)(w[4]);    ...    return w+5;}
and the dsp_add method should be called like this:dsp_add((t_perfroutine)wrap_ 
overshoot_tilde_perform, 4, (t_int)x, (t_int)sp[0]->s_vec, (t_int)sp[1]->s_vec, 
(t_int)sp[0]->s_n);
About what you want to do, I would like to help but I'm not sure to understand. 
I understand that you want that your object performs at the end of the DSP 
chain (end of the audio block) on a signal that should be computed previously 
in the DSP chain but as we all know only the Matthew McConaughey from 
Interstellar has this power :).
Cheers,
Pierre
2016-09-29 12:00 GMT+02:00 Ed Kelly via Pd-dev :

Hey list,I'm tearing my hair out trying to re-write the wrap~ object, so that 
it doesn't wrap instantly but waits until the end of the audio block to wrap~ 
the signal. I hope you understand.
This is so that control-rate messages sent to another object further down the 
signal-path have a chance to catch up, and eliminate clicks due to the 
end-of-block delay for control messages.
The idea is that wrap_overshoot~ will not wrap until the end of the block. This 
is a really tech-y problem, but I've tried variables and clocks. Everything 
seems to segfault on me.
?Lots of love,Ed
PS if this works you'll all be able to use it during and after pdcon16~

__ _
Pd-dev mailing list
pd-...@lists.iem.at
https://lists.puredata.info/ listinfo/pd-dev





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

[PD] developing externals with Vult

[Leonardo Laguna]

Hi, I thought that this can be interesting for people developing DSP code
for PD.

In the latest version of Vult https://github.com/modlfo/vult it is possible
to create PD audio externals. If you don't know it, Vult is a domain
specific language that simplifies coding DSP algorithms and generates C++,
Js and Lua code. You can find more information in the webpage.

Vult has a template that automatically generates the code for a PD audio
extension, here's an example https://github.com/modlfo/pd-vult-example

I hope you like it,

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

Re: [PD] [PD-dev] Rewrite wrap~ to allow an extra block

[Pierre Guillot]

Hi Ed,
The prototype of your perform method is wrong. You should have something
like:
static t_int *wrap_overshoot_tilde_perform(t_int *w)
{
t_wrap_overshoot_tilde *x = (t_wrap_overshoot_tilde *)(w[1]);
t_sample *in  = (t_sample *)(w[2]);
t_sample *out = (t_sample *)(w[3]);
t_int n   = (t_int)(w[4]);
...
return w+5;
}

and the dsp_add method should be called like this:
dsp_add((t_perfroutine)wrap_overshoot_tilde_perform, 4, (t_int)x, (t_int)sp[
0]->s_vec, (t_int)sp[1]->s_vec, (t_int)sp[0]->s_n);

About what you want to do, I would like to help but I'm not sure to
understand. I understand that you want that your object performs at the end
of the DSP chain (end of the audio block) on a signal that should be
computed previously in the DSP chain but as we all know only the Matthew
McConaughey from Interstellar has this power :).

Cheers,

Pierre

2016-09-29 12:00 GMT+02:00 Ed Kelly via Pd-dev :

> Hey list,
> I'm tearing my hair out trying to re-write the wrap~ object, so that it
> doesn't wrap instantly but waits until the end of the audio block to wrap~
> the signal. I hope you understand.
>
> This is so that control-rate messages sent to another object further down
> the signal-path have a chance to catch up, and eliminate clicks due to the
> end-of-block delay for control messages.
>
> The idea is that wrap_overshoot~ will not wrap until the end of the block.
> This is a really tech-y problem, but I've tried variables and clocks.
> Everything seems to segfault on me.
>
> ?
> Lots of love,
> Ed
>
> PS if this works you'll all be able to use it during and after pdcon16~
>
> ___
> Pd-dev mailing list
> pd-...@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Rewrite wrap~ to allow an extra block

[Ed Kelly via Pd-list]

Hey list,I'm tearing my hair out trying to re-write the wrap~ object, so that 
it doesn't wrap instantly but waits until the end of the audio block to wrap~ 
the signal. I hope you understand.
This is so that control-rate messages sent to another object further down the 
signal-path have a chance to catch up, and eliminate clicks due to the 
end-of-block delay for control messages.
The idea is that wrap_overshoot~ will not wrap until the end of the block. This 
is a really tech-y problem, but I've tried variables and clocks. Everything 
seems to segfault on me.
?Lots of love,Ed
PS if this works you'll all be able to use it during and after pdcon16~
#include "m_pd.h"

typedef struct wrap_overshoot_tilde
{
t_object x_obj;
t_float x_f;
  int overShoot, shootFlag, k_i;
  t_float token, storeLast;
  t_sample f_s;
  t_clock *x_clock;

} t_wrap_overshoot_tilde;

t_class *wrap_overshoot_tilde_class;

void wrap_overshoot_tilde_tick(t_wrap_overshoot_tilde *x)
{
  x->shootFlag = 1;


}

static void *wrap_overshoot_tilde_new(void)
{
t_wrap_overshoot_tilde *x = (t_wrap_overshoot_tilde *)pd_new(wrap_overshoot_tilde_class);
outlet_new(>x_obj, gensym("signal"));
x->x_f = 0;
x->overShoot = 0;
x->shootFlag = 0;
x->f_s = 0;
x->k_i = 0;
x->storeLast = 0;
x->x_clock = clock_new(x, (t_method)wrap_overshoot_tilde_tick);
return (x);
}

static t_int *wrap_overshoot_tilde_perform(t_int *w, t_wrap_overshoot_tilde *x)
{
t_sample *in = *(t_sample **)(w+1), *out = *(t_sample **)(w+2);
t_int n = *(t_int *)(w+3);
/*if(x->overShoot > 0)
  {
	x->shootFlag = 1;
	//	x->overShoot = 0;
  }
else if(x->overShoot == 0)
  {
	x->shootFlag = 1;
	}*/

	// else if(x->overShoot == 0) x->shootFlag = 0;
while(n--)
{
x->f_s = *in++;
x->k_i = x->f_s;
	if (x->storeLast < 1 && (x->f_s - x->k_i) >= 1)
	  {
	//	*out++ = x->f_s - x->k_i;
	clock_delay(x->x_clock, 0);
	  }
	if(x->shootFlag == 1)
	  {
	*out++ = x->f_s - x->k_i;
	  }
	else if (x->f_s > 0) *out++ = x->f_s - x->k_i;
else *out++ = x->f_s - (x->k_i - 1);
	x->storeLast = (float)(x->f_s - x->k_i);
}
if(x->shootFlag == 1) x->shootFlag = 0;
return (w + 4);
}

static void wrap_overshoot_tilde_dsp(t_wrap_overshoot_tilde *x, t_signal **sp)
{
dsp_add(wrap_overshoot_tilde_perform, 3, sp[0]->s_vec, sp[1]->s_vec, sp[0]->s_n);
}

void wrap_overshoot_tilde_setup(void)
{
  wrap_overshoot_tilde_class = class_new(gensym("wrap_overshoot~"), 
  (t_newmethod)wrap_overshoot_tilde_new, 
  0, sizeof(t_wrap_overshoot_tilde),
  CLASS_DEFAULT, A_DEFFLOAT, 0);
CLASS_MAINSIGNALIN(wrap_overshoot_tilde_class, t_wrap_overshoot_tilde, x_f);
class_addmethod(wrap_overshoot_tilde_class, (t_method)wrap_overshoot_tilde_dsp,
gensym("dsp"), A_CANT, 0);
}
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [text] question (SOLVED)

[José Rafael Subía Valdez]

Final update,

thanks IOhannes,

I managed to send the required bang after the text file is loaded and only
then the other messages are pushed.. no [delay]

cheers

On Thu, Sep 29, 2016 at 8:50 AM, José Rafael Subía Valdez <
jsubiaval...@gmail.com> wrote:

> definitely,
>
> I will see if there is a better and more elegant way to do this.. I guess
> I can send a bang from the [text define] when the file is loaded and only
> then push the others to find that buffer.
>
> I will work on this today
>
> thanks IOhannes
>
>
>
> On Thu, Sep 29, 2016 at 8:39 AM, IOhannes m zmoelnig 
> wrote:
>
>> On 2016-09-29 10:02, José Rafael Subía Valdez wrote:
>> > I solved this by
>> > setting a short delay after the [init]
>>
>> this (forcing events into the correct order by adding indefined delays
>> here and there) is generally a bad idea.
>>
>> a better one would be to signal via an explicit message to the readers
>> that data is now available.
>>
>> hmsdf
>> IOhannes
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
>
> --
> José Rafael Subía Valdez
> www.jrsv.net
>
>
>
>
>


-- 
José Rafael Subía Valdez
www.jrsv.net
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [text] question (SOLVED)

[José Rafael Subía Valdez]

definitely,

I will see if there is a better and more elegant way to do this.. I guess I
can send a bang from the [text define] when the file is loaded and only
then push the others to find that buffer.

I will work on this today

thanks IOhannes



On Thu, Sep 29, 2016 at 8:39 AM, IOhannes m zmoelnig 
wrote:

> On 2016-09-29 10:02, José Rafael Subía Valdez wrote:
> > I solved this by
> > setting a short delay after the [init]
>
> this (forcing events into the correct order by adding indefined delays
> here and there) is generally a bad idea.
>
> a better one would be to signal via an explicit message to the readers
> that data is now available.
>
> hmsdf
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>


-- 
José Rafael Subía Valdez
www.jrsv.net
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [text] question (SOLVED)

[IOhannes m zmoelnig]

On 2016-09-29 10:02, José Rafael Subía Valdez wrote:
> I solved this by
> setting a short delay after the [init]

this (forcing events into the correct order by adding indefined delays
here and there) is generally a bad idea.

a better one would be to signal via an explicit message to the readers
that data is now available.

hmsdf
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] [text] question (SOLVED)

[José Rafael Subía Valdez]

Thanks Liam for your help,

I revised the patch and it was actually an error caused by the abstractions
trying to read the "buffer" before it actually loaded, I solved this by
setting a short delay after the [init]

cheers

On Thu, Sep 29, 2016 at 7:17 AM, José Rafael Subía Valdez <
jsubiaval...@gmail.com> wrote:

> Thanks Liam,
>
> the read instruction is in [GUI-creator]. I thought the other object need
> the name as a pointer, the creation arguments are written as they should
> be, other wise the patch wouldn't work at all, $2  inside is because it
> comes from the second argument written in the [cr_gui] abstraction.
>
> thanks for your help, I will continue to revise it, but if anyone else has
> an idea why this is happening I am all ears,
>
> cheers
>
>
>
> On Thu, Sep 29, 2016 at 6:51 AM, Liam Goodacre 
> wrote:
>
>> The problem is coming from the "read_number_memory" subpatches, where the
>> [text search] and [text set] objects are not linked to a text buffer. I
>> can't tell exactly why this is. Could it be because the creation arguments
>> are confused? ($1 in the [text define] object, $2 in the abstraction).
>>
>>
>> If not, perhaps you are misunderstanding how the text objects work. The
>> name given in [text define] defines a buffer that other text objects can
>> reference, but it does not point to a specific text file on your hard
>> drive. To open a file from the hard disk, you must send a "read" message to
>> text define. I don't see such a message in your patch, so perhaps this is
>> the problem.
>>
>>
>> --
>> *From:* Pd-list  on behalf of José Rafael
>> Subía Valdez 
>> *Sent:* 28 September 2016 20:59
>> *To:* pd-list
>> *Subject:* [PD] [text] question
>>
>> Hello list
>>
>> quick question about the [text] object, I have a patch that reads and
>> records a text file. I use various [text] objects in the patch that access
>> the same file, these are placed in abstractions. I have no problems when
>> running the patch and the program works, but when I close the patch I get
>> this error, and I can't figure out why.
>>
>> text: couldn't find text buffer 'test-GUI-amount.txt'
>>
>> any ideas?
>>
>> last part of a 4-week project. So maybe I need a pair of fresh eyes.
>>
>> Basically, it is a preset system that I am programming, I keep track of
>> how many objects have been created, I am recording this number into a text
>> file. And I am using a single text file for every GUI object that I am
>> using. I don't understand why the error only comes up when closing the
>> patch or deleting the module that contains the objects. The program works
>> as I want it, but I would really wanna get rid of this error.
>>
>> attached is the file if someone can take a look, I deeply appreciate it.
>> To reproduce the error just open and close the patch. The [text] object is
>> in the
>> [GUI-creator] module and in the [pd read_number_memory] subpatch in the
>> [cr_gui] abstraction
>>
>> what is clear is that the error comes from the use of [text] in the
>> [cr_gui] as I have 8 errors and I use 8 instances of this abstraction
>>
>> cheers
>>
>> --
>> José Rafael Subía Valdez
>> www.jrsv.net
>> JRSV | Official website 
>> www.jrsv.net
>> Home. Welcome to my website, here you will find information regarding my
>> work in different fields of research and production. Find out about my
>> projects that involve ...
>>
>>
>>
>>
>>
>>
>
>
> --
> José Rafael Subía Valdez
> www.jrsv.net
>
>
>
>
>


-- 
José Rafael Subía Valdez
www.jrsv.net
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [text] question

[José Rafael Subía Valdez]

Thanks Liam,

the read instruction is in [GUI-creator]. I thought the other object need
the name as a pointer, the creation arguments are written as they should
be, other wise the patch wouldn't work at all, $2  inside is because it
comes from the second argument written in the [cr_gui] abstraction.

thanks for your help, I will continue to revise it, but if anyone else has
an idea why this is happening I am all ears,

cheers



On Thu, Sep 29, 2016 at 6:51 AM, Liam Goodacre  wrote:

> The problem is coming from the "read_number_memory" subpatches, where the
> [text search] and [text set] objects are not linked to a text buffer. I
> can't tell exactly why this is. Could it be because the creation arguments
> are confused? ($1 in the [text define] object, $2 in the abstraction).
>
>
> If not, perhaps you are misunderstanding how the text objects work. The
> name given in [text define] defines a buffer that other text objects can
> reference, but it does not point to a specific text file on your hard
> drive. To open a file from the hard disk, you must send a "read" message to
> text define. I don't see such a message in your patch, so perhaps this is
> the problem.
>
>
> --
> *From:* Pd-list  on behalf of José Rafael
> Subía Valdez 
> *Sent:* 28 September 2016 20:59
> *To:* pd-list
> *Subject:* [PD] [text] question
>
> Hello list
>
> quick question about the [text] object, I have a patch that reads and
> records a text file. I use various [text] objects in the patch that access
> the same file, these are placed in abstractions. I have no problems when
> running the patch and the program works, but when I close the patch I get
> this error, and I can't figure out why.
>
> text: couldn't find text buffer 'test-GUI-amount.txt'
>
> any ideas?
>
> last part of a 4-week project. So maybe I need a pair of fresh eyes.
>
> Basically, it is a preset system that I am programming, I keep track of
> how many objects have been created, I am recording this number into a text
> file. And I am using a single text file for every GUI object that I am
> using. I don't understand why the error only comes up when closing the
> patch or deleting the module that contains the objects. The program works
> as I want it, but I would really wanna get rid of this error.
>
> attached is the file if someone can take a look, I deeply appreciate it.
> To reproduce the error just open and close the patch. The [text] object is
> in the
> [GUI-creator] module and in the [pd read_number_memory] subpatch in the
> [cr_gui] abstraction
>
> what is clear is that the error comes from the use of [text] in the
> [cr_gui] as I have 8 errors and I use 8 instances of this abstraction
>
> cheers
>
> --
> José Rafael Subía Valdez
> www.jrsv.net
> JRSV | Official website 
> www.jrsv.net
> Home. Welcome to my website, here you will find information regarding my
> work in different fields of research and production. Find out about my
> projects that involve ...
>
>
>
>
>
>


-- 
José Rafael Subía Valdez
www.jrsv.net
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [text] question

[Liam Goodacre]

The problem is coming from the "read_number_memory" subpatches, where the [text 
search] and [text set] objects are not linked to a text buffer. I can't tell 
exactly why this is. Could it be because the creation arguments are confused? 
($1 in the [text define] object, $2 in the abstraction).


If not, perhaps you are misunderstanding how the text objects work. The name 
given in [text define] defines a buffer that other text objects can reference, 
but it does not point to a specific text file on your hard drive. To open a 
file from the hard disk, you must send a "read" message to text define. I don't 
see such a message in your patch, so perhaps this is the problem.



From: Pd-list  on behalf of José Rafael Subía 
Valdez 
Sent: 28 September 2016 20:59
To: pd-list
Subject: [PD] [text] question

Hello list

quick question about the [text] object, I have a patch that reads and records a 
text file. I use various [text] objects in the patch that access the same file, 
these are placed in abstractions. I have no problems when running the patch and 
the program works, but when I close the patch I get this error, and I can't 
figure out why.

text: couldn't find text buffer 'test-GUI-amount.txt'

any ideas?

last part of a 4-week project. So maybe I need a pair of fresh eyes.

Basically, it is a preset system that I am programming, I keep track of how 
many objects have been created, I am recording this number into a text file. 
And I am using a single text file for every GUI object that I am using. I don't 
understand why the error only comes up when closing the patch or deleting the 
module that contains the objects. The program works as I want it, but I would 
really wanna get rid of this error.

attached is the file if someone can take a look, I deeply appreciate it. To 
reproduce the error just open and close the patch. The [text] object is in the
[GUI-creator] module and in the [pd read_number_memory] subpatch in the 
[cr_gui] abstraction

what is clear is that the error comes from the use of [text] in the [cr_gui] as 
I have 8 errors and I use 8 instances of this abstraction

cheers

--
José Rafael Subía Valdez
www.jrsv.net
JRSV | Official website
www.jrsv.net
Home. Welcome to my website, here you will find information regarding my work 
in different fields of research and production. Find out about my projects that 
involve ...






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

Re: [PD] purr data beta1

[Alexandre Torres Porres]

awesome, more and more excited at each new development step

so, Scope~ is already ported, but [comment]  is not working yet, are you
dealing with it?

cheers

2016-09-29 1:51 GMT-03:00 Jonathan Wilkes via Pd-list 
:

> This is the beta 1 release of Purr Data (the GUI port of Pd-l2ork)
>
> Change log:
> * fix many errors in the GUI
> * fix position of popup menu when zooming
> * fix scalar crasher
> * fix gop display error
> * fix disappearing $@
> * save gui preset with preferences
> * fix segfault with preference changes
> * fixed many memory leaks with patches backported from Pd Vanilla
> * small fixes to help patches
> * add text editor window for [text define]
> * add and improve the scalar properties dialog
> * add default float arg for Pd's "quit" message (good for test patches)
> * updated some external libraries
>
> This is a beta release, so please report lots of bugs to
> https://git.purrdata.net/jwilkes/purr-data/issues
>
> Binaries here:
> https://git.purrdata.net/jwilkes/purr-data-binaries/tree/master
>
> -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