Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued?

[Hans-Christoph Steiner]

The problem with changing t_widgetbehavior is that it breaks binary 
compatibililty, I think.  That makes it a pain to manage the transition.  
Personally, I think it'd be worthwhile to use the struct as it.  Or really, I'd 
like to see bigger changes to offload more stuff to the GUI, like mouse motion 
and click handling, resizing, etc.  For a resize of an object, 'pd' only needs 
to know about it once its done, not while its happening.

.hc

On Nov 4, 2011, at 11:36 PM, Ivica Ico Bukvic wrote:

> Because after studying the code it looked like a difficult thing to pull off. 
> This is because the regular displacefn is used for initial posting of objects 
> which is absolute in nature while displacewithtag is relative, so the two 
> don’t play very nice.
>  
> HTH
>  
> Ico
>  
> From: Hans-Christoph Steiner [mailto:h...@at.or.at] 
> Sent: Friday, November 04, 2011 6:26 PM
> To: Ivica Ico Bukvic
> Cc: pd-list@iem.at
> Subject: Re: [PD] how to capture window-related mouse-events when toxy 
> isdiscontinued?
>  
>  
> Hey Ico,
>  
> What not just use the displacefn to do the move with tags?  Then we wouldn't 
> need to change that core struct.
>  
> .hc
>  
> Ivica Ico Bukvic  wrote:
> The said changes are in pre-git tarballs. I think they are also listed in the 
> changelog under a specific date which should make things a bit easier to 
> isolate. That said, implementation alters widgetbehavior struct by adding one 
> more entry and as such it breaks compatibility with gridflow unless 
> recompiled from scratch using the new .h file. Even then there might be other 
> incompatibilities. That said, I've encountered none, other than gridflow. Of 
> course, other externals need to be recompiled as well (but no changes to 
> their source are required).
> 
> HTH
> 
> Best wishes,
> 
> Ico
> 
> Ivica Ico Bukvic, D.M.A
> Composition, Music Technology
> Director, DISIS Interactive Sound & Intermedia Studio
> Director, L2Ork Linux Laptop Orchestra
> Assistant Director, CCTAD
> Virginia Tech
> Department of Music
> Blacksburg, VA 24061-0240
> (540) 231-6139
> (540) 231-5034 (fax)
> disis.music.vt.edu
> l2ork.music.vt.edu
> ico.bukvic.net
> 
> Hans-Christoph Steiner  wrote:
>  
> Hey Ico,
>  
> That's great, we need to do a lot more of that.  Can you point me to where 
> these changes are so I can check them out?
>  
> .hc
>  
> On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:
> 
> 
> Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing 
> everything, out issues single tcl/tk command. The only thing that still 
> redrawed every time when displaced is gop-enabled patcher.
> 
> Ivica Ico Bukvic, D.M.A
> Composition, Music Technology
> Director, DISIS Interactive Sound & Intermedia Studio
> Director, L2Ork Linux Laptop Orchestra
> Assistant Director, CCTAD
> Virginia Tech
> Department of Music
> Blacksburg, VA 24061-0240
> (540) 231-6139
> (540) 231-5034 (fax)
> disis.music.vt.edu
> l2ork.music.vt.edu
> ico.bukvic.net
> 
> Jonathan Wilkes  wrote:
> I believe Ivica made such a modification in Pd-l2ork-- whatever the case, 
> moving many iemguis in 
> 
> Pd-l2ork is much snappier than in Vanilla or Pd-extended.  But I haven't 
> measured the cpu load.
> 
> 
> 
> -Jonathan
> 
> 
> 
> 
> 
> - Original Message -
> 
> > From: Hans-Christoph Steiner 
> 
> > To: João Pais 
> 
> > Cc: katja ; "pd-list@iem.at" ; 
> > Jonathan Wilkes 
> 
> > Sent: Thursday, November 3, 2011 11:07 AM
> 
> > Subject: Re: [PD] how to capture window-related mouse-events when toxy is 
> > discontinued?
> 
> > 
> 
> > 
> 
> > I
> doubt that Tcl/Tk's drawing code is being overloaded.  Instead, try 
> 
> > running "path/to/pd -stderr -d 3" and you'll see that 'pd' 
> 
> > is sending 'pd-gui' massive amounts of Tcl code to pa!
>  rse,
> compile, and 
> 
> > execute.  In the case of a move, this could be accomplished with one line 
> > of Tcl 
> 
> > to tag everything you want to move, then one move command to let Tcl/Tk do 
> > the 
> 
> > moving.
> 
> > 
> 
> > .hc
> 
> > 
> 
> > On Nov 3, 2011, at 10:31 AM, João Pais wrote:
> 
> > 
> 
> >>  those spikes is what I was predicting with the graphic overloading of 
> 
> > tcl/tk (through data structures, in this case).
> 
> >> 
> 
> >>  you could also try the following: make the "selectable area" 
> 
> > around one corner (or middle) of the button: with a tiny bit more 
> > resolution, 
> 
> > but less points in the template. if you want to keep the squares, it's even 
> 
> > better, because it helps you selecting the structs.
> 
> >> 
> 
> >>  Or one other thing: maybe can the tcl/tk code be changed, so that it 
> 
> > doesn't overload that fast? Reduce the redraw rate, or something else? (I 
> 
> > h!
>  ave no
> idea about tcl/tk)
> 
> >> 
> 
> >>  Or change the output rate of the struct object? (this might not help much)
> 
> >> 
> 
> >> 
> 
> >>  About the background grid for instant jumps, an implementation of it in 
> >> run 
> 
> > mode is easy. I could try to give an exam

Re: [PD] how to capture window-related mouse-events when toxy isdiscontinued?

[Ivica Ico Bukvic]

Because after studying the code it looked like a difficult thing to pull off. 
This is because the regular displacefn is used for initial posting of objects 
which is absolute in nature while displacewithtag is relative, so the two don’t 
play very nice.

 

HTH

 

Ico

 

  _  

From: Hans-Christoph Steiner [mailto:h...@at.or.at] 
Sent: Friday, November 04, 2011 6:26 PM
To: Ivica Ico Bukvic
Cc: pd-list@iem.at
Subject: Re: [PD] how to capture window-related mouse-events when toxy 
isdiscontinued?

 

 

Hey Ico,

 

What not just use the displacefn to do the move with tags?  Then we wouldn't 
need to change that core struct.

 

.hc

 

Ivica Ico Bukvic  wrote:

The said changes are in pre-git tarballs. I think they are also listed in the 
changelog under a specific date which should make things a bit easier to 
isolate. That said, implementation alters widgetbehavior struct by adding one 
more entry and as such it breaks compatibility with gridflow unless recompiled 
from scratch using the new .h file. Even then there might be other 
incompatibilities. That said, I've encountered none, other than gridflow. Of 
course, other externals need to be recompiled as well (but no changes to their 
source are required).

HTH

Best wishes,

Ico

Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu  
l2ork.music.vt.edu  
ico.bukvic.net  

Hans-Christoph Steiner  wrote:

 

Hey Ico,

 

That's great, we need to do a lot more of that.  Can you point me to where 
these changes are so I can check them out?

 

.hc

 

On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:





Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing 
everything, out issues single tcl/tk command. The only thing that still 
redrawed every time when displaced is gop-enabled patcher.

Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu  
l2ork.music.vt.edu  
ico.bukvic.net  

Jonathan Wilkes  wrote:

I believe Ivica made such a modification in Pd-l2ork-- whatever the case, 
moving many iemguis in 


Pd-l2ork is much snappier than in Vanilla or Pd-extended.  But I haven't 
measured the cpu load.





-Jonathan








- Original Message -


> From: Hans-Christoph Steiner 


> To: João Pais 


> Cc: katja ; "pd-list@iem.at" ; 
> Jonathan Wilkes 


> Sent: Thursday, November 3, 2011 11:07 AM


> Subject: Re: [PD] how to capture window-related mouse-events when toxy is 
> discontinued?


> 


> 


> I
doubt that Tcl/Tk's drawing code is being overloaded.  Instead, try 


> running "path/to/pd -stderr -d 3" and you'll see that 'pd' 


> is sending 'pd-gui' massive amounts of Tcl code to pa!
 rse,
compile, and 


> execute.  In the case of a move, this could be accomplished with one line of 
> Tcl 


> to tag everything you want to move, then one move command to let Tcl/Tk do 
> the 


> moving.


> 


> .hc


> 


> On Nov 3, 2011, at 10:31 AM, João Pais wrote:


> 


>>  those spikes is what I was predicting with the graphic overloading of 


> tcl/tk (through data structures, in this case).


>> 


>>  you could also try the following: make the "selectable area" 


> around one corner (or middle) of the button: with a tiny bit more resolution, 


> but less points in the template. if you want to keep the squares, it's even 


> better, because it helps you selecting the structs.


>> 


>>  Or one other thing: maybe can the tcl/tk code be changed, so that it 


> doesn't overload that fast? Reduce the redraw rate, or something else? (I 


> h!
 ave no
idea about tcl/tk)


>> 


>>  Or change the output rate of the struct object? (this might not help much)


>> 


>> 


>>  About the background grid for instant jumps, an implementation of it in run 


> mode is easy. I could try to give an example, but don't have any time for 


> now.


>> 


>> 


>>>  - Original Message -


  From: katja 


  To: pd-list@iem.at


  Cc:


  Sent: Thursday, November 3, 2011 6:10 AM


  Subject: Re: [PD] how to capture window-related mouse-events when 


> toxy is discontinued?


 


  On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes 


> 


 
wrote:


 


>  How does the cpu usage in my demo!
  compare
to your patch where 


> you use


>  a radiobutton?


 


  Here's a cpu load comparison of objects dragged continuously 


> (on intel


  mac 2GHz):


>>

Re: [PD] Interruption of audio / Loading sound into array

[Jonathan Wilkes]

- Original Message -

> From: Hans-Christoph Steiner 
> To: Mathieu Bouchard 
> Cc: Jonathan Wilkes ; "pd-list@iem.at" 
> Sent: Friday, November 4, 2011 7:01 PM
> Subject: Re: [PD] Interruption of audio / Loading sound into array
> 
> 
> On Nov 4, 2011, at 2:08 PM, Mathieu Bouchard wrote:
> 
>>  Le 2011-11-04 à 10:51:00, Jonathan Wilkes a écrit :
>> 
>>>  Well if it works it should go into Pd-extended 0.43.  But if it goes 
> into Pd-extended 0.43, who will maintain it if there are bugs?
>> 
>>  What power would be granted to such a maintainer to ensure that the 
> bugfixes do get in pd-extended binaries ?
> 
> Everyone has the power, they just need to do the work.

Right.

This feature is a reasonable request with considerable demand (as it keeps 
popping up on the list).  Since some form of it seems to have already been 
coded, there needs to be a way to incorporate it into Pd extended without 
requiring Hans to do all the work, on the one hand, and without requiring an 
additional maintainer to vouch to be its guardian for all eternity.

Would it be possible to have one or more devs to a) steward it into an alpha
state that can be included in the nightly builds and b) keep an eye on it 
through 
the next version of Pd in case of bugs?  That way there are specific goals, so 
that any interested Pders could fund a dev (or more than one dev) to achieve 
these, without requiring those devs to "adopt" the object class as their 
permanent 
responsibility, and without piling more work on Hans in the leadup to and 
maintenance of 0.43.

-Jonathan

> 
> .hc
> 
> 
> 
> 
> 
> 
> "Free software means you control what your computer does. Non-free software 
> means someone else controls that, and to some extent controls you." - 
> Richard M. Stallman
>

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

Re: [PD] Interruption of audio / Loading sound into array

[Hans-Christoph Steiner]

On Nov 4, 2011, at 2:08 PM, Mathieu Bouchard wrote:

> Le 2011-11-04 à 10:51:00, Jonathan Wilkes a écrit :
> 
>> Well if it works it should go into Pd-extended 0.43.  But if it goes into 
>> Pd-extended 0.43, who will maintain it if there are bugs?
> 
> What power would be granted to such a maintainer to ensure that the bugfixes 
> do get in pd-extended binaries ?

Everyone has the power, they just need to do the work.

.hc






"Free software means you control what your computer does. Non-free software 
means someone else controls that, and to some extent controls you." - Richard 
M. Stallman



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

Re: [PD] how to capture window-related mouse-events when toxy is discontinued?

[Hans-Christoph Steiner]

Hey Ico,

What not just use the displacefn to do the move with tags?  Then we wouldn't 
need to change that core struct.

.hc

Ivica Ico Bukvic  wrote:
The said changes are in pre-git tarballs. I think they are also listed in the 
changelog under a specific date which should make things a bit easier to 
isolate. That said, implementation alters widgetbehavior struct by adding one 
more entry and as such it breaks compatibility with gridflow unless recompiled 
from scratch using the new .h file. Even then there might be other 
incompatibilities. That said, I've encountered none, other than gridflow. Of 
course, other externals need to be recompiled as well (but no changes to their 
source are required).

HTH

Best wishes,

Ico

Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

Hans-Christoph Steiner  wrote:

Hey Ico,

That's great, we need to do a lot more of that.  Can you point me to where 
these changes are so I can check them out?

.hc

On Nov 3, 2011, at 2:44 PM, Ivica Ico Bukvic wrote:

> Indeed, pd-l2ork moves entire selection by tag, so instead of redrawing 
> everything, out issues single tcl/tk command. The only thing that still 
> redrawed every time when displaced is gop-enabled patcher.
> 
> Ivica Ico Bukvic, D.M.A
> Composition, Music Technology
> Director, DISIS Interactive Sound & Intermedia Studio
> Director, L2Ork Linux Laptop Orchestra
> Assistant Director, CCTAD
> Virginia Tech
> Department of Music
> Blacksburg, VA 24061-0240
> (540) 231-6139
> (540) 231-5034 (fax)
> disis.music.vt.edu
> l2ork.music.vt.edu
> ico.bukvic.net
> 
> Jonathan Wilkes  wrote:
> I believe Ivica made such a modification in Pd-l2ork-- whatever the case, 
> moving many iemguis in 
> Pd-l2ork is much snappier than in Vanilla or Pd-extended.  But I haven't 
> measured the cpu load.
> 
> -Jonathan
> 
> 
> - Original Message -
> > From: Hans-Christoph Steiner 
> > To: João Pais 
> > Cc: katja ; "pd-list@iem.at" ; 
> > Jonathan Wilkes 
> > Sent: Thursday, November 3, 2011 11:07 AM
> > Subject: Re: [PD] how to capture window-related mouse-events when toxy is 
> > discontinued?
> > 
> > 
> > I
> doubt that Tcl/Tk's drawing code is being overloaded.  Instead, try 
> > running "path/to/pd -stderr -d 3" and you'll see that 'pd' 
> > is sending 'pd-gui' massive amounts of Tcl code to pa!
>  rse,
> compile, and 
> > execute.  In the case of a move, this could be accomplished with one line 
> > of Tcl 
> > to tag everything you want to move, then one move command to let Tcl/Tk do 
> > the 
> > moving.
> > 
> > .hc
> > 
> > On Nov 3, 2011, at 10:31 AM, João Pais wrote:
> > 
> >>  those spikes is what I was predicting with the graphic overloading of 
> > tcl/tk (through data structures, in this case).
> >> 
> >>  you could also try the following: make the "selectable area" 
> > around one corner (or middle) of the button: with a tiny bit more 
> > resolution, 
> > but less points in the template. if you want to keep the squares, it's even 
> > better, because it helps you selecting the structs.
> >> 
> >>  Or one other thing: maybe can the tcl/tk code be changed, so that it 
> > doesn't overload that fast? Reduce the redraw rate, or something else? (I 
> > h!
>  ave no
> idea about tcl/tk)
> >> 
> >>  Or change the output rate of the struct object? (this might not help much)
> >> 
> >> 
> >>  About the background grid for instant jumps, an implementation of it in 
> >> run 
> > mode is easy. I could try to give an example, but don't have any time for 
> > now.
> >> 
> >> 
> >>>  - Original Message -
>   From: katja 
>   To: pd-list@iem.at
>   Cc:
>   Sent: Thursday, November 3, 2011 6:10 AM
>   Subject: Re: [PD] how to capture window-related mouse-events when 
> > toxy is discontinued?
>  
>   On Thu, Nov 3, 2011 at 1:30 AM, Jonathan Wilkes 
> > 
>  
> wrote:
>  
> >  How does the cpu usage in my demo!
>   compare
> to your patch where 
> > you use
> >  a radiobutton?
>  
>   Here's a cpu load comparison of objects dragged continuously 
> > (on intel
>   mac 2GHz):
>  
>   polygon in movable_box2.pd: 23 %
>   polygon in 07.sequencer.pd (help browser): 16%
>   radiobutton in moving_objects.pd: 12 %
>   regular Pd slider: 13 %
>   2D geo in a gem window: 2.5%
> >>> 
> >>>  I just got intermittent rises up to 50% on a dual core 64-bit amd with
> >>>  all of the above.
> >>> 
> >>>  I imagine that the cpu load for movable_box2.pd is due to the number of
> >>>  points in the polygon.  I think you could get a 20x20 draggable square 
> > with 8 coordinates-- that
> >>>  would be equal to the number of p!
>  oints in
> a radiobutton so maybe that 
> > would get down
> >>>  t

Re: [PD] expr alternative

[Andy Farnell]

I'll pitch EU 50. (while its still worth anything)

And politely encourage RjDj to dig in too.

I've made my feelings clear enough about Apple.



On Fri, 4 Nov 2011 09:29:59 +0100
Olivier B  wrote:

> 2011/11/4 i go bananas 
> 
> > apple just rang me.
> >
> > as andy predicted, they are still being highly cagey and will not give a
> > yes/no answer to me.  grrr.
> >
> > however, what they told me, was to go part of the way through developer
> > registration, so i could read the "ios_program_standard_agreement", in
> > which case i would "find what i need to know".
> >
> > here's the clause that pertains to FOSS licensing:
> >
> > "3.3.20If Your Application includes any FOSS, You agree to comply with
> > all applicable FOSS licensing terms. You also agree not to use any FOSS in
> > the development of Your Application in such a way that would cause the
> > non-FOSS portions of the Apple Software to be subject to any FOSS licensing
> > terms or obligations."
> >
> >
> > so, to my simple mind, it appears that LGPL IS allowed in iOS
> > applications, as long as you make the source available in a way that is
> > LGPL compliant.
> >
> > the only thing that bothers me, is this section of the iOS agreement:
> >
> > "7.1Delivery of Freely Available Licensed Applications via the App
> > Store; Certificates
> > If Your Application qualifies as a Licensed Application, it is eligible
> > for delivery to end-users via the App Store by Apple and/or an Apple
> > Subsidiary. If You would like Apple and/or an Apple Subsidiary to deliver
> > Your Licensed Application or authorize additional content, functionality or
> > services You make available in Your Licensed Application through the use of
> > the In App Purchase API to end-users for free (no charge) via the App
> > Store, then You appoint Apple and Apple Subsidiaries as Your legal agent
> > pursuant to the terms of Schedule 1, for Licensed Applications designated
> > by You as free of charge applications.
> >
> > If Your Application qualifies as a Licensed Application and You intend to
> > charge end-users a fee of any kind for Your Licensed Application or within
> > Your Licensed Application through the use of the In App Purchase API, You
> > must enter into a separate agreement (Schedule 2) with Apple and/or an
> > Apple Subsidiary before any such commercial distribution of Your Licensed
> > Application may take place via the App Store or before any such commercial
> > delivery of additional content, functionality or services for which you
> > charge end-users a fee may be authorized through the use of the In App
> > Purchase API in Your Licensed Application."
> >
> > i'm not sure if those clauses have any effect on using LGPL code?
> >
> > Anyway, this is the information i have so far, and i thought i should
> > share it.
> >
> > It appears to me that if Mr Yadegari and IRCAM are willing to license expr
> > under the LGPL, then there's a good chance that the 'full' vanilla
> > distribution would be allowed in iOS applications.
> >
> > it's very hard for me to continue looking into this matter, because there
> > are some fairly significant moral issues and despite my laughing at people
> > a little bit, i actually do think these things through, and it's a bit of a
> > difficult situation.
> >
> > if people are following this issue, and just not saying anything, then it
> > would help to get a clearer consensus of the 'community view' here, as i
> > feel very uncomfortable about pushing this issue if i am going against the
> > general consensus.
> >
> > to outline so far, there seem to be 3 main options:
> >
> > 1) leave expr as GPL
> > 2) take up Mr Yadegari's offer to re-license under the LGPL
> > 3) raise some money or incentive for Mr Yadegari to re-write expr code to
> > be BSD compliant
> 
> 
> 3) I offer 10€... who's next ?
> 
> 
> 
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 4, 2011 at 8:50 AM, Olivier B wrote:
> >
> >> 2011/11/2 Jonathan Wilkes 
> >>
> >>> >
> >>> >From: Olivier B 
> >>> >To: i go bananas 
> >>> >Cc: PD-List 
> >>> >Sent: Wednesday, November 2, 2011 8:01 AM
> >>> >Subject: Re: [PD] expr alternative
> >>> >
> >>> >
> >>> >Hi list...
> >>> >
> >>> >Just to say that, even if my patchs are published under GPL, as I
> >>> definitely need my lines to be straight (or not aliased), I would prefer
> >>> [expr] to be under BSD, like Pd-Vanilla is...
> >>>
> >>> What does the license have to do with straight lines and aliasing?
> >>>
> >>
> >> Sorry list...
> >>
> >> I've certainly done a private joke only to myself... :-/
> >> I just wanted to say that I like my Pd patches to be tidy... to have
> >> their lines (or wires, I don't know the word used in english) perfectly
> >> straight...
> >> And for the same reason, it disturbs me to know that Pd-vanilla doesn't
> >> offers the same license for all of its code... it makes disorder...
> >> (but don't worry for me... every day, I'm getting better (damed, how it's
> >

Re: [PD] Interruption of audio / Loading sound into array

[Jonathan Wilkes]

- Original Message -
> From: Mathieu Bouchard 
> To: Jonathan Wilkes 
> Cc: katja ; "pd-list@iem.at" 
> Sent: Friday, November 4, 2011 2:08 PM
> Subject: Re: [PD] Interruption of audio / Loading sound into array
> 
> Le 2011-11-04 à 10:51:00, Jonathan Wilkes a écrit :
> 
>>  Well if it works it should go into Pd-extended 0.43.  But if it goes into 
> Pd-extended 0.43, who will maintain it if there are bugs?
> 
> What power would be granted to such a maintainer to ensure that the bugfixes 
> do 
> get in pd-extended binaries ?

Well if it's a libdir external it would be easy, right?

If it's a replacement for [soundfiler] I'm not sure.

-Jonathan

> 
> __
> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC
>

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

[PD] Rép : PDGST - no pix_gst2pix... and building Gem 0.93 with mac OS 10.6

[x.garnier]

Good evening,
I've downloaded Gem 0.93.1 but I didn't succeed in installing it.
I've tried to :

- download the last version of pd-extended but it's 0.42.5 and it's mine (which 
also means that I have Gem 0.92).

- get some informations here : 
http://gem.iem.at/documentation/faq/how-do-you-compile-gem-on-osx and then :

- use build/osx-xcode but I don't know what to do inside Xcode as I have a lot 
of files in red (missing ?) and I've never tried to "build and run" with Xcode 
before (I'm no developer at all unfortunately) ...

- build Gem in 
/Applications/Pd-extended.app/Contents/Resources/extra/Gem-0.93.1 with :

./configure --disable-dependency-tracking --enable-fat-binary=ppc,i386 
PKG_FTGL_CFLAGS="-I/usr/local/include/FTGL $(freetype-config --cflags)" 
PKG_FTGL_LIBS="-L/usr/local/lib/ -lftgl -lfreetype"

which is the command you advise to use.
but then I get this message :
--
<...> 
 Install path   : /usr/local

 pure-data:
  version: 0.0
  extension  : pd_darwin

 used optional libraries:

  font-rendering : FTGL

  image-support
use ImageMagick  : no
use TIFF : no
use JPEG : no
  moviefile-support
use PLUGINS  : yes
use mpeg : no
use mpeg-3   : no
use QuickTime: yes (framework)
use aviplay  : no
use gmerlin  : no
  capture-support
use PLUGINS  : yes
use v4l  : no
use v4l2 : no
use ieee1394 : no

configure: error: Pd (header) is mandatory and seems to be missing!
---
I don't actually have any folder named Pd (exept an alias), only pdextended, 
I've tried to build Gem 0.93.1 in several locations but I get that same message 
all the time...
I'm sorry that must be a stupid problem but if could give me some hints to try 
to install Gem 0.93.1 (do I have do delete Gem 0.92 by the way ? how if needed 
?), I hope I'll be able to reinstall pdgst with the gst2pix object this time...
thanks a lot

Xavier

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-10-31 00:37, x.garnier wrote:
> Hello you all, 

> pix_gst2pix.cpp:148: error: ?class GemState? has no member named ?set?
> pix_gst2pix.cpp:148: error: ?_PIX? is not a member of ?GemState?


it seems like you are trying to compile pdgst with an older version
(<0.93) of Gem.
it also seems like pdgst currently only builds with Gem>=0.93

i hope i find time to make pdgst backward compatible.


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

Re: [PD] Interruption of audio / Loading sound into array

[Mathieu Bouchard]

Le 2011-11-04 à 10:51:00, Jonathan Wilkes a écrit :

Well if it works it should go into Pd-extended 0.43.  But if it goes 
into Pd-extended 0.43, who will maintain it if there are bugs?


What power would be granted to such a maintainer to ensure that the 
bugfixes do get in pd-extended binaries ?


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Interruption of audio / Loading sound into array

[katja]

-- Forwarded message --
From: katja 
Date: Fri, Nov 4, 2011 at 7:06 PM
Subject: Re: [PD] Interruption of audio / Loading sound into array
To: pd-...@iem.at


On Fri, Nov 4, 2011 at 5:21 PM, Mathieu Bouchard  wrote:


> I don't find anything named like « threaded soundfiler » in the sourceforge
> tracker, so, it's possible that it hadn't submitted. But that might have
> been already the time at which we started to doubt that things submitted in
> the tracker forms were likely to be accepted.




Thomas Grill pointed to the code. It is all in the trunk of
pure-data.svn: externals/tb/sndfiler and externals/grh/threadlib. But
it is not included in the build system.


Katja

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

Re: [PD] how to capture window-related mouse-events when toxy is discontinued?

[Mathieu Bouchard]

Le 2011-11-04 à 10:37:00, Jonathan Wilkes a écrit :

It seems like it does redraw stuff between the delete and create for a 
scalar with enough canvas items associated with it.  For example, if you 
make a ds array where each element is a little 10x10 rectangle and plot 
it with an array size greater than 100, you start to get a kind of 
strobing effect over the entire array when moving one element with the 
mouse.


Ok, whenever you do see it blink, then it's probably quite less efficient 
than with «coords».


(though sometimes, some benchmarks give surprising results. but it's hard 
to benchmark it completely... I had to modify Tk to get it to print the 
time it takes to redraw, because that part of Tk isn't overridable from 
Tcl nor from a C plugin for Tcl).


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Interruption of audio / Loading sound into array

[Jonathan Wilkes]

- Original Message -

> From: Mathieu Bouchard 
> To: katja 
> Cc: pd-list@iem.at
> Sent: Friday, November 4, 2011 12:21 PM
> Subject: Re: [PD] Interruption of audio / Loading sound into array
> 
> Le 2011-11-04 à 11:26:00, katja a écrit :
> 
>>  By coincidence I noticed an svn commit access request from Damian
>>  Stewart, back in 2008, where he proposes to 'implement multithreaded
>>  [soundfiler] read'
> 
> But (multi)threaded [soundfiler] had already been implemented in 2005 (or 
> 2004 ?) by Tim Blechmann.
> 
> This and other things didn't get accepted by Miller's branch. In the 
> end, Blechmann decided to become a SuperCollider developer and apparently has 
> stopped using pd.
> 
> His threaded [soundfiler] is not in 0.43 either.

Well if it works it should go into Pd-extended 0.43.  But if it goes into 
Pd-extended 
0.43, who will maintain it if there are bugs?

-Jonathan

> 
>>  [readsf~] and writesf~] are threaded, they operate in a child process.
>>  I guess it could not be otherwise? Because they do not intend to read
>>  all samples at once.
> 
> No, they could read it with a single thread, but it would be bad for latency, 
> because the process could be blocked while waiting for the harddisk, and on 
> top 
> of that, the non-blocking mode (of read/write) usually doesn't work for 
> ordinary files (when I tried, it only worked on pipes and sockets and perhaps 
> some other things, but not ordinary files).
> 
>>  Looking at the code in d_soundfile.c, I can understand why the whole of Pd 
> should not be multithreaded.
> 
> Look for a branch named devel_0_39.
> 
> I don't find anything named like « threaded soundfiler » in the sourceforge 
> tracker, so, it's possible that it hadn't submitted. But that might have 
> been already the time at which we started to doubt that things submitted in 
> the 
> tracker forms were likely to be accepted.
> 
>>  It is a lot of overhead. But [soundfiler~] read is another exceptional case 
> indeed, it needs carefully scheduled loading if it is not to cause buffer 
> underruns elsewhere. Such loading in portions would also mean the whole 
> audiofile is not immediately available in memory. Therefore, the result would 
> somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick.
> 
> If [readsf~]-in-an-upsampled-patch is really a good trick, I dare Miller to 
> publish it as an abstraction with pd, which would be called soundfiler2.pd or 
> similar.
> 
> But no abstractions at all are provided with pd, except demos in the 
> tutorials. 
> Which is weird for software in which most users rely heavily on abstractions.
> 
> __
> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>

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

Re: [PD] how to capture window-related mouse-events when toxy is discontinued?

[Jonathan Wilkes]

- Original Message -

> From: Mathieu Bouchard 
> To: Jonathan Wilkes 
> Cc: katja ; "pd-list@iem.at" 
> Sent: Friday, November 4, 2011 1:18 PM
> Subject: Re: [PD] how to capture window-related mouse-events when toxy is 
> discontinued?
> 
> Le 2011-11-04 à 07:37:00, Jonathan Wilkes a écrit :
> 
>>  Functionally there is no difference between altering a polygon's shape 
> and the way I am moving it.
> 
> In Tk, to change the coordinates of a canvas-item, you don't have to delete 
> it and recreate it. There's always a canvas-method named « coords » that 
> takes the same number of position arguments that the item-constructor did. So 
> for a rectangle-item, you give two points (four numbers) and for a N-gon 
> (N-sided polygon), you give N points (2*N points).
> 
> It might not be much faster, though. I expect it to be only a tiny bit 
> faster. 
> Just a bit less time parsing, about one less malloc and one less free 
> (perhaps 
> several, because you have to remove a tag and add back the exact same). It 
> doesn't actually redraw anything between the delete and the create.

It seems like it does redraw stuff between the delete and create for a scalar 
with 
enough canvas items associated with it.  For example, if you make a ds array 
where each element is a 
little 10x10 rectangle and plot it with an array size greater than 100, you 
start to get a 
kind of strobing effect over the entire array when moving one element with the 
mouse.

> 
> Now that I think of it, the bbox computation (necessary for scheduling the 
> redraw) is done twice using create/delete, only once using coords, but that 
> should be a small amount of time compared to parsing the command.
> 
> BTW, extremely long strings of commands might be parsed repeatedly by the 
> client 
> side in pd 43, because it's using [info complete] (just like desiredata). 
> But in practice, I didn't see it be a problem in profiling desiredata's 
> client's cpu usage, and I think pd 43 does it just the same.
> I didn't profile in all situations, though, so, the technique might hit 
> problems with big arrays, big DS, big moves or abuse of [print] or of other 
> post()/error().
> 
> __
> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC
>

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

Re: [PD] how to capture window-related mouse-events when toxy is discontinued?

[Mathieu Bouchard]

Le 2011-11-04 à 07:37:00, Jonathan Wilkes a écrit :

Functionally there is no difference between altering a polygon's shape 
and the way I am moving it.


In Tk, to change the coordinates of a canvas-item, you don't have to 
delete it and recreate it. There's always a canvas-method named « coords » 
that takes the same number of position arguments that the item-constructor 
did. So for a rectangle-item, you give two points (four numbers) and for a 
N-gon (N-sided polygon), you give N points (2*N points).


It might not be much faster, though. I expect it to be only a tiny bit 
faster. Just a bit less time parsing, about one less malloc and one less 
free (perhaps several, because you have to remove a tag and add back the 
exact same). It doesn't actually redraw anything between the delete and 
the create.


Now that I think of it, the bbox computation (necessary for scheduling the 
redraw) is done twice using create/delete, only once using coords, but 
that should be a small amount of time compared to parsing the command.


BTW, extremely long strings of commands might be parsed repeatedly by the 
client side in pd 43, because it's using [info complete] (just like 
desiredata). But in practice, I didn't see it be a problem in profiling 
desiredata's client's cpu usage, and I think pd 43 does it just the same.
I didn't profile in all situations, though, so, the technique might hit 
problems with big arrays, big DS, big moves or abuse of [print] or of 
other post()/error().


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbol2list leading zero

[Mathieu Bouchard]

Le 2011-11-04 à 17:44:00, rolf meesters a écrit :


with trial&error i came up with a quite complicated patch
for the task to convert a MAC addres in the form 00-ab-7d- etc
into it's equivalent without the '-' character.


Two solutions, a long one using [gf/l2s] and [gf/s2l] (which Roman calls 
« not practical »), and a shorter one using [gf/string_replace].


#N canvas 0 0 450 184 10;
#X msg 6 -2 symbol 00-11-ab-7d-85-04;
#X obj 6 18 gf/s2l -;
#X obj 6 38 gf/l2s;
#X msg 61 38 symbol;
#X obj 61 18 loadbang;
#X obj 6 58 print;
#X msg 6 88 symbol 00-11-ab-7d-85-04;
#X obj 6 108 gf/string_replace -;
#X obj 6 128 print;
#X text 107 38 symbol message without symbol means empty string;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 5 0;
#X connect 3 0 2 1;
#X connect 4 0 3 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] symbol2list leading zero

[rolf meesters]

with trial&error i came up with a quite complicated patch
for the task to convert a MAC addres in the form 00-ab-7d- etc
into it's equivalent without the '-' character.

any comment is welcomed

rolf

#N canvas 104 217 569 343 10;
#X obj -94 16 symbol2list -;
#X obj -75 125 makefilename %.2s;
#X obj -94 45 list-drip;
#X obj -55 103 makefilename %.02d;
#X obj -108 163 symbol;
#X obj -94 74 t b a a;
#X obj -39 164 t l;
#X obj -129 223 list;
#X obj -129 269 list2symbol;
#X obj -108 190 list prepend;
#X msg -66 243 symbol;
#X obj -66 217 loadbang;
#X obj -23 76 s end_drip;
#X obj -185 185 r end_drip;
#X obj -129 304 print;
#X text -22 242 -- get rid of the blanks;
#X msg -94 -12 symbol 00-11-ab-7d-85-04;
#X text 64 98 --makefilename %.2d: in case of a number restores leading
zero \, in case of a symbol gives a zero.;
#X text 23 139 --makefilename %.2s:in case of a number no output \,
in case of a symbol overwrites the unwanted zero.;
#X text 68 -14 --example of the expected input;
#X connect 0 0 2 0;
#X connect 1 0 4 1;
#X connect 2 0 5 0;
#X connect 2 1 12 0;
#X connect 3 0 4 1;
#X connect 4 0 9 0;
#X connect 5 0 4 0;
#X connect 5 1 1 0;
#X connect 5 2 3 0;
#X connect 6 0 9 1;
#X connect 7 0 8 0;
#X connect 8 0 14 0;
#X connect 9 0 6 0;
#X connect 9 0 7 1;
#X connect 10 0 8 1;
#X connect 11 0 10 0;
#X connect 13 0 7 0;
#X connect 16 0 0 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] expr alternative

[Mathieu Bouchard]

Le 2011-11-04 à 08:52:00, Jonathan Wilkes a écrit :

No, I'm serious.  I'll pay $200 for a replacement set of such objects 
where numbers are by default interpreted as floats like the rest of Pd.


Oh, you mean 3/2==1.5 in the context of what gets written in [expr] 
boxes... for some reason, I didn't think of it when you wrote that at 
first.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Interruption of audio / Loading sound into array

[Mathieu Bouchard]

Le 2011-11-04 à 11:50:00, Roman Haefeli a écrit :

The problem with the '[readsf~]-in-an-upsampled-patch' approach is that 
you cannot know how fast you can do it without interrupting audio. Also 
you cannot really fine-tune it since you can only set it to a speed to 
any power of two. Ideally, a threaded [soundfiler] would load the file 
as fas as possible in the background without interfering with Pd's main 
process and then it would output a bang when done.


Even if you do tune one [readsf~] to load at an appropriate speed, you 
need global control to figure out how many [readsf~] can run at once and 
how much upsampling you have to do on each. Then you really need to make 
this an abstraction (or a set thereof) because this coordination is 
getting too complex for copy-paste.


Blechmann-and/or-Grill's solution was to make a queue like this :

static struct t_sfqueue {
t_sfprocess *begin;
t_sfprocess *end;
pthread_mutex_t mutex;
pthread_cond_t cond;
} *soundfiler_queue;

Where each t_sfprocess saves soundfiler messages for later, remembering 
the content and destination... and also the next-pointer for making a 
linked-list.


So, this means that there is only one soundfiler running at a time, which 
might be faster on the hard disk or not. Depends on which hard-disks they 
are on and whether they're cached and stuff. It's hard to get smart about 
it, but running only one soundfiler thread isn't a bad idea.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Interruption of audio / Loading sound into array

[Mathieu Bouchard]

Le 2011-11-04 à 11:26:00, katja a écrit :


By coincidence I noticed an svn commit access request from Damian
Stewart, back in 2008, where he proposes to 'implement multithreaded
[soundfiler] read'


But (multi)threaded [soundfiler] had already been implemented in 2005 (or 
2004 ?) by Tim Blechmann.


This and other things didn't get accepted by Miller's branch. In the end, 
Blechmann decided to become a SuperCollider developer and apparently 
has stopped using pd.


His threaded [soundfiler] is not in 0.43 either.


[readsf~] and writesf~] are threaded, they operate in a child process.
I guess it could not be otherwise? Because they do not intend to read
all samples at once.


No, they could read it with a single thread, but it would be bad for 
latency, because the process could be blocked while waiting for the 
harddisk, and on top of that, the non-blocking mode (of read/write) 
usually doesn't work for ordinary files (when I tried, it only worked on 
pipes and sockets and perhaps some other things, but not ordinary files).


Looking at the code in d_soundfile.c, I can understand why the whole of 
Pd should not be multithreaded.


Look for a branch named devel_0_39.

I don't find anything named like « threaded soundfiler » in the 
sourceforge tracker, so, it's possible that it hadn't submitted. But that 
might have been already the time at which we started to doubt that things 
submitted in the tracker forms were likely to be accepted.


It is a lot of overhead. But [soundfiler~] read is another exceptional 
case indeed, it needs carefully scheduled loading if it is not to cause 
buffer underruns elsewhere. Such loading in portions would also mean the 
whole audiofile is not immediately available in memory. Therefore, the 
result would somehow be equivalent to the 
'[readsf~]-in-an-upsampled-patch' trick.


If [readsf~]-in-an-upsampled-patch is really a good trick, I dare Miller 
to publish it as an abstraction with pd, which would be called 
soundfiler2.pd or similar.


But no abstractions at all are provided with pd, except demos in the 
tutorials. Which is weird for software in which most users rely heavily on 
abstractions.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] expr alternative

[Jonathan Wilkes]

- Original Message -
> From: Mathieu Bouchard 
> To: Jonathan Wilkes 
> Cc: Olivier B ; i go bananas ; 
> PD-List 
> Sent: Friday, November 4, 2011 11:39 AM
> Subject: Re: [PD] expr alternative
> 
> Le 2011-11-04 à 07:16:00, Jonathan Wilkes a écrit :
> 
>>  I'll put up $200 for a 3-clause-BSD-licensed [expr] family replacement 
> where 3 / 2 = 1.5
> 
> 3/2 = 1.5 ?
> 
> Is that another « private joke » ?

No, I'm serious.  I'll pay $200 for a replacement set of such objects where 
numbers are by default interpreted as floats like the rest of Pd.

-Jonathan

> 
> Olivier a écrit :
>>  Just to say that, even if my patchs are published under 
> GPL, as I definitely need my lines to be straight (or not aliased), I would 
> prefer [expr] to be under BSD, like Pd-Vanilla is...
  I've certainly done a private joke only to myself... :-/
> 
> __
> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC
>

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

Re: [PD] expr alternative

[Mathieu Bouchard]

Le 2011-11-04 à 07:16:00, Jonathan Wilkes a écrit :

I'll put up $200 for a 3-clause-BSD-licensed [expr] family replacement 
where 3 / 2 = 1.5


3/2 = 1.5 ?

Is that another « private joke » ?

Olivier a écrit :
Just to say that, even if my patchs are published under GPL, as I 
definitely need my lines to be straight (or not aliased), I would 
prefer [expr] to be under BSD, like Pd-Vanilla is...

I've certainly done a private joke only to myself... :-/


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] expr alternative

[Mathieu Bouchard]

Le 2011-11-04 à 16:28:00, i go bananas a écrit :

"7.1    Delivery of Freely Available Licensed Applications via the App 
Store; Certificates If Your Application qualifies as a Licensed 
Application, it is eligible for delivery to end-users via the App Store 
by Apple and/or an Apple Subsidiary. If You would like Apple and/or an 
Apple Subsidiary to deliver Your Licensed Application or authorize 
additional content, functionality or services You make available in Your 
Licensed Application through the use of the In App Purchase API to 
end-users for free (no charge) via the App Store, then You appoint Apple 
and Apple Subsidiaries as Your legal agent pursuant to the terms of 
Schedule 1, for Licensed Applications designated by You as free of 
charge applications.


Wow, does this means I can't sue Apple if they ever do anything 
reprehensible with my free-of-charge app ? I have to trust that they will 
agree to sue themselves... :}


Well, the trick is easy. You charge a nominal 0,01 $. Anyway, for Free 
Software (GPL/LGPL), any amount whatsoever may be charged for the final 
packages. The only money restriction is that you can't charge much extra 
for the source code, although no actual limit is stated in the license 
texts. For the executables, you could charge 66,66 $ for GPL/LGPL 
software in the App Store and the FSF wouldn't give a damn (legally... 
though they might think your business model is dumb).


The only problem with 0,01 $ would then be that one has to pay the cent, 
and possibly extra transaction fees, rather than just click OK. Well, I 
never have used App Store, so I don't really know how much hassle and how 
much more fees it means, but as a substitute, I'm thinking of the 
difference between an unrestricted website vs one that wants to sell me a 
lot of content for a single payment of 0,01 $ via PayPal.


If Your Application qualifies as a Licensed Application and You intend 
to charge end-users a fee of any kind for Your Licensed Application or 
within Your Licensed Application through the use of the In App Purchase 
API, You must enter into a separate agreement (Schedule 2)


What's the « Schedule 2 » that they are talking about ?

with Apple and/or an Apple Subsidiary before any such commercial 
distribution of Your Licensed Application may take place via the App 
Store or before any such commercial delivery of additional content, 
functionality or services for which you charge end-users a fee may be 
authorized through the use of the In App Purchase API in Your Licensed 
Application."


Although the App Store is a big thing, this does not limit your ability to 
charge money in general (outside of App Store). It only applies when 
distributing in the App Store.


But is it ok to have to get additional permission from Apple for being 
allowed to charge something ? This sounds like it could conflict.


It appears to me that if Mr Yadegari and IRCAM are willing to license 
expr under the LGPL, then there's a good chance that the 'full' vanilla 
distribution would be allowed in iOS applications. 


Have you read this ?

http://www.fsf.org/blogs/community/why-free-software-and-apples-iphone-dont-mix

(says last modified oct 2011, but is listed somewhere else as first 
released july 2008)


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Osx Lion PD-extended problem

[hans w. koch]

sorry for chiming in very late, but i ran into the exact same problem today on 
a students computer while giving a pd-workshop in seoul.
the solution was quite funny: after a lot of head scratching, it dawned on me, 
that he might have pirated software from a certain company installed and in 
order to prevent the software from telephoning home, messed with his hosts file 
in /etc.
asking him out via the translator revealed, that this was indeed the case, only 
that he hadn´t applied the hack correctly and deleted the line "127.0.0.1   
localhost" from his hosts file.
restoring that line made pd boot again.

hope this helps somebody in similar woes...
hans

www.hans-w-koch.net


> Date: Wed, 26 Oct 2011 01:03:29 +0300
> From: Arda Eden 
> Subject: Re: [PD] Osx Lion PD-extended problem
> To: Hans-Christoph Steiner 
> Cc: pd-list@iem.at
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> With Pd-0.42.5-extended-macosx106-x86_64.dmg the actual error message is :
> 
> localhost not found (inet protocol not installed ?)
> 
> On Wed, Oct 26, 2011 at 12:56 AM, Arda Eden  wrote:
> 
>> Both x86 and x86_64 versions are saying :
>> 
>> ERROR: failed to allocate port, exiting !
>> 
>> 
>> On Wed, Oct 26, 2011 at 12:31 AM, Hans-Christoph Steiner 
>> wrote:
>> 
>>> 
>>> That's an odd one.  Which version of Pd-extended are you using?  Have you
>>> tried a nightly build?
>>> 
>>> http://autobuild.puredata.**info/auto-build/latest/
>>> 
>>> .hc
>>> 
>>> 
>>> On Oct 25, 2011, at 5:17 PM, Arda Eden wrote:
>>> 
>>> Today I encountered a problem with Pd-extended on Osx Lion today.
 
 Application not responding. When I run it from terminal I get "inet
 protocol not installed ?" message.
 Everything was fine with it when I last ran it. And no docs on the net.
 Any idea ?
 Thanks.
 
 --
 Arda EDEN
 Inonu University
 Faculty of Fine Arts and Design
 Department of Music Technology
 Malatya/TURKEY
 __**_
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management -> http://lists.puredata.info/**
 listinfo/pd-list 
 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --**--**
>>> 
>>> 
>>> "[T]he greatest purveyor of violence in the world today [is] my own
>>> government." - Martin Luther King, Jr.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Arda EDEN
>> Inonu University
>> Faculty of Fine Arts and Design
>> Department of Music Technology
>> Malatya/TURKEY
>> 
> 
> 
> 
> -- 
> Arda EDEN
> Inonu University
> Faculty of Fine Arts and Design
> Department of Music Technology
> Malatya/TURKEY
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> ___
> Pd-list mailing list
> Pd-list@iem.at
> to manage your subscription (including un-subscription) see
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> End of Pd-list Digest, Vol 79, Issue 117
> 


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

Re: [PD] symbol2list leading zero

[Mathieu Bouchard]

Le 2011-11-04 à 08:56:00, Roman Haefeli a écrit :

You said "(as it is like with any string-splitter outside of pd/max)". I 
should have said it more precisely: It doesn't make sense to compare 
Pd/Max with anything outside of Pd/Max regarding string-splitting, 
because 'just' splitting symbols (without the implicit conversion to 
float for number-like symbols) is not very practical in the Pd/World.


How do you know that it isn't practical to have numeric symbols when 
splitting ?


If I read /etc/passwd (list of users on Linux&OSX) and I split at colons 
and commas to get phone numbers, do you think I want Pd's help at rounding 
a phone number from 383.3801 to 383.38 when converting (aller-retour) from 
symbol to float to symbol, because it had too many significant digits for 
Pd's taste ?


So, just call me at 383.38 because it's more practical than dialling 
383.3801 ! ;)


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] how to capture window-related mouse-events when toxy is discontinued?

[Jonathan Wilkes]

- Original Message -
> From: katja 
> To: pd-list@iem.at
> Cc: 
> Sent: Friday, November 4, 2011 5:23 AM
> Subject: Re: [PD] how to capture window-related mouse-events when toxy is 
> discontinued?
> 
> On Fri, Nov 4, 2011 at 3:46 AM, Jonathan Wilkes  
> wrote:
> 
>>  Oh, wow-- lines, polygons, and text of scalars get deleted and recreated 
> every time they
>>  get moved.  This is what gets sent to the GUI for every motion event when 
> dragging a
>>  scalar (in run mode here):
>> 
>>  .x291cf70.c delete curve291f238
>>  .x291cf70.c delete curve291f238
>>  .x291cf70.c create polygon\
>>  217 175\
>>  227 175\
>>  227 185\
>>  217 185\
>>  -width 1.00\
>>  -fill #ff -outline #00\
>>  -tags curve291f238
>>  .x291cf70.c create line\
>>  172 130\
>>  272 130\
>>  272 230\
>>  172 230\
>>  172 130\
>>  -width 1.00\
>>  -fill #00\
>>  -tags curve291f238
>> 
>>  I imagine if this were changed to tag the entire scalar and move it by tag,
>>  it would improve the performance quite a bit.
> 
> Possibly the idea behind the polygons was more to manipulate (or
> visually represent) the character of sound by altering a polygon's
> shape.

Functionally there is no difference between altering a polygon's shape and 
the way I am moving it.

> See help browser >> 4.data.structures/07.sequencer.pd. Then it
> is obvious that a polygon must be redrawn everytime.

It doesn't have to get deleted and recreated each time, does it?  Wouldn't 
a single canvas coords subcommand be more efficient?

> In my view,
> changing shapes is much more imaginative than dragging fixed shapes
> around. But in live performance, it is easier to hit a 50*50 pix
> square on a touch screen and drag it around, than trying to pick a
> polygon's minuscule corner with a mouse.

If you're just moving shapes, you might consider doing everything in edit 
mode with [cnv] objects-- it will be more efficient than data structures (which 
still get deleted when moving them in edit mode-- don't understand that at all) 
and you can track their position with the "get_pos" message.

-Jonathan

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

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

Re: [PD] expr alternative

[Jonathan Wilkes]

>
>From: Olivier B 
>To: i go bananas 
>Cc: Jonathan Wilkes ; PD-List 
>Sent: Friday, November 4, 2011 4:29 AM
>Subject: Re: [PD] expr alternative
>
>
>2011/11/4 i go bananas 
>
>apple just rang me.  
>>
>>as andy predicted, they are still being highly cagey and will not give a 
>>yes/no answer to me.  grrr.
>>
>>however, what they told me, was to go part of the way through developer 
>>registration, so i could read the "ios_program_standard_agreement", in which 
>>case i would "find what i need to know".
>>
>>here's the clause that pertains to FOSS licensing:
>>
>>"3.3.20    If Your Application includes any FOSS, You agree to comply with 
>>all applicable FOSS licensing terms. You also agree not to use any FOSS in 
>>the development of Your Application in such a way that would cause the 
>>non-FOSS portions of the Apple Software to be subject to any FOSS licensing 
>>terms or obligations."
>>
>>
>>so, to my simple mind, it appears that LGPL IS allowed in iOS applications, 
>>as long as you make the source available in a way that is LGPL compliant.
>>
>>the only thing that bothers me, is this section of the iOS agreement:
>>
>>"7.1    Delivery of Freely Available Licensed Applications via the App Store; 
>>Certificates
>>If Your Application qualifies as a Licensed Application, it is eligible for 
>>delivery to end-users via the App Store by Apple and/or an Apple Subsidiary. 
>>If You would like Apple and/or an Apple Subsidiary to deliver Your Licensed 
>>Application or authorize additional content, functionality or services You 
>>make available in Your Licensed Application through the use of the In App 
>>Purchase API to end-users for free (no charge) via the App Store, then You 
>>appoint Apple and Apple Subsidiaries as Your legal agent pursuant to the 
>>terms of Schedule 1, for Licensed Applications designated by You as free of 
>>charge applications.
>>
>>If Your Application qualifies as a Licensed Application and You intend to 
>>charge end-users a fee of any kind for Your Licensed Application or within 
>>Your Licensed Application through the use of the In App Purchase API, You 
>>must enter into a separate agreement (Schedule 2) with Apple and/or an Apple 
>>Subsidiary before any such commercial distribution of Your Licensed 
>>Application may take place via the App Store or before any such commercial 
>>delivery of additional content, functionality or services for which you 
>>charge end-users a fee may be authorized through the use of the In App 
>>Purchase API in Your Licensed Application."
>>
>>i'm not sure if those clauses have any effect on using LGPL code?
>>
>>Anyway, this is the information i have so far, and i thought i should share 
>>it.  
>>
>>It appears to me that if Mr Yadegari and IRCAM are willing to license expr 
>>under the LGPL, then there's a good chance that the 'full' vanilla 
>>distribution would be allowed in iOS applications.  
>>
>>it's very hard for me to continue looking into this matter, because there are 
>>some fairly significant moral issues and despite my laughing at people a 
>>little bit, i actually do think these things through, and it's a bit of a 
>>difficult situation.
>>
>>if people are following this issue, and just not saying anything, then it 
>>would help to get a clearer consensus of the 'community view' here, as i feel 
>>very uncomfortable about pushing this issue if i am going against the general 
>>consensus.  
>>
>>to outline so far, there seem to be 3 main options:
>>
>>1) leave expr as GPL
>>2) take up Mr Yadegari's offer to re-license under the LGPL
>>3) raise some money or incentive for Mr Yadegari to re-write expr code to be 
>>BSD compliant
>
>3) I offer 10€... who's next ?

I'll put up $200 for a 3-clause-BSD-licensed [expr] family replacement where 3 
/ 2 = 1.5

>
> 
>
>>
>>
>>
>>
>>
>>
>>On Fri, Nov 4, 2011 at 8:50 AM, Olivier B  wrote:
>>
>>2011/11/2 Jonathan Wilkes 
>>>

>From: Olivier B 
>To: i go bananas 
>Cc: PD-List 
>Sent: Wednesday, November 2, 2011 8:01 AM

>Subject: Re: [PD] expr alternative
>
>

>Hi list...
>
>Just to say that, even if my patchs are published under GPL, as I 
>definitely need my lines to be straight (or not aliased), I would prefer 
>[expr] to be under BSD, like Pd-Vanilla is...

What does the license have to do with straight lines and aliasing?

>>>
>>>Sorry list...
>>>
>>>I've certainly done a private joke only to myself... :-/
>>>I just wanted to say that I like my Pd patches to be tidy... to have their 
>>>lines (or wires, I don't know the word used in english) perfectly 
>>>straight... 
>>>And for the same reason, it disturbs me to know that Pd-vanilla doesn't 
>>>offers the same license for all of its code... it makes disorder...
>>>(but don't worry for me... every day, I'm getting better (damed, how it's 
>>>hard to try to make humor in a foreign language :-p ) )
>>>
>>>C

[PD] Mac OS X/PowerPC nightly builds are back

[Hans-Christoph Steiner]

After a pretty long hiatus, the Mac OS X/PowerPC builds are back. The plan is 
to have a fully supported PowerPC build for at least this release.  Gem is 
currently not included in the Mac OS X builds, but will be again soon, but 
otherwise, please try this build and let me know how it works for you:

http://autobuild.puredata.info/auto-build/latest/

.hc



Access to computers should be unlimited and total.  - the hacker ethic



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

[PD] sssad saving big messages to text files

[berenger recoules]

Hello list,

I'm trying to use sssad to save content of a patch designed to be used with
PdDroidParty. I understand the way it works for numbers and tables but is
there a way to save a full message to a textfile ? but more precisely how
to store several messages into the same textfile ?

I want to save data coming from the c_taptap abs from the rjdj lib, and
also save the analysis result of markov chains; both of which get dumped
into a message.

1-on the first hand for the c_taptap abs the message would look like this:
[0, 2, 8, (
2-on the second hand markov messages would be something like this : [3, 27,
3, 9, 33, 9, 7, 31, 7, 5, 17, 5, 11, 35, 11, 3, 15, 3, 0, 0, 0, 3, 27, 3,
9, 9, 9, 7, 19, 7, 5, 29, (

-> 1 should be easy enough I could dump that to a table or even unpack to
single values since i know the max size of the message.
-> the main issue is with the second type of message since the max size
will change each time the chains are trained. I could dump it into a "big
enough" table to be saved, but it doesn't seem very elegant. Is there a way
to dynamically resize tables ? or a better way to do what I want ?

thanks for reading


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

Re: [PD] Interruption of audio / Loading sound into array

[katja]

On Fri, Nov 4, 2011 at 11:41 AM, Thomas Grill  wrote:
> Hi all,
> have you had a look at this:
> http://grh.mur.at/software/sndfiler.html
> It used to work for me, although i haven't tried for a long time (that is,
> with current pd versions)
> gr~~~


Hi Thomas,

Thanks for pointing to this. Seems like a very systematic approach.
All the code is in pure-data.svn, but grh and tb libs are not included
in 0.42 or 0.43 binary builds. Apparently these libs are no longer
maintainded, and don't fit in the actual build system. At least the
code is there, and it could just be a matter of reviving (parts of)
it, who knows.

Katja

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

Re: [PD] Interruption of audio / Loading sound into array

[Pierre-Olivier Boulant]

Hi,

This seems to have been debated several times. It's one of those 
recurring subjects.
If I had only one wish for Pd it would be to have a non blocking/low 
priority [soundfiler] alternative.



I have the same trouble as mentioned. I have no graph for the tables, 
it's not a GUI issue. I thought the problem would go away with a faster 
disk, I switched from a rather fast laptop HDD to an SSD. No luck, not 
even the slightest improvement. The problem does seem to go away with a 
speedier CPU even-though the processor is not under a real strain from 
the rest of the patch. The bottle neck here is CPU crunching speed. This 
would mean for me either changing computer or changing my sound card for 
just little drop outs or switch to Live and M4L. :(
Loading more stuff at the beginning is just not an option, I have 
already a lot loaded and I don't want the restriction of only playing 
with predetermined stuff.



I had to increase Pd's latency to 300ms to get rid of this on a Core2duo 
1.6GHz processor and split the different files into short mono files 
which restrict the number of elements in each sound bank I'm loading. As 
this patch is a random sample player running in auto it's not so 
important if there is some latency, I'm more concerned with the length 
restriction.
More bugging is the MIDI latency that follows the sound latency. It 
really makes things awkward because you have to either be very slow and 
patient when moving the controls (it can break the MIDI connexion with 
looping even if I patched something that tries to prevent that) or split 
the MIDI subpatch into a separate patch and have net-send/receive on 
both sides.



Most people loading stuff for sample players already handle the 
restricted access to the tables being loaded. As long as something 
happens at the end of the loading (output of the file length) it's ok, 
we know when loading starts and finishes.


Sorry if I sound raunchy. It's one hassle I have with Pd and my coding 
knowledge being what it is I can't do more than rant. :)


Cheers
Pierre-Olivier


On 04/11/2011 11:26, katja wrote:

By coincidence I noticed an svn commit access request from Damian
Stewart, back in 2008, where he proposes to 'implement multithreaded
[soundfiler] read'
(http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html).
What has become of this? Is there any code from this project?

[readsf~] and writesf~] are threaded, they operate in a child process.
I guess it could not be otherwise? Because they do not intend to read
all samples at once. Looking at the code in d_soundfile.c, I can
understand why the whole of Pd should not be multithreaded. It is a
lot of overhead. But [soundfiler~] read is another exceptional case
indeed, it needs carefully scheduled loading if it is not to cause
buffer underruns elsewhere. Such loading in portions would also mean
the whole audiofile is not immediately available in memory. Therefore,
the result would somehow be equivalent to the
'[readsf~]-in-an-upsampled-patch'  trick. But, like Charles pointed
out, it is not trivial to find an optimum. I agree Pd should better do
this in C.

Katja

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



--


~Pierre-Olivier Boulant ~
-o- www.puffskydd.net -o-
~   www.flickr.com/pob31/sets   ~
-o-www.lepixophone.net-o-
 



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

Re: [PD] Interruption of audio / Loading sound into array

[Roman Haefeli]

On Fri, 2011-11-04 at 11:26 +0100, katja wrote:
> By coincidence I noticed an svn commit access request from Damian
> Stewart, back in 2008, where he proposes to 'implement multithreaded
> [soundfiler] read'
> (http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html).
> What has become of this? Is there any code from this project?
> 
> [readsf~] and writesf~] are threaded, they operate in a child process.
> I guess it could not be otherwise? Because they do not intend to read
> all samples at once. Looking at the code in d_soundfile.c, I can
> understand why the whole of Pd should not be multithreaded. It is a
> lot of overhead. But [soundfiler~] read is another exceptional case
> indeed, it needs carefully scheduled loading if it is not to cause
> buffer underruns elsewhere. Such loading in portions would also mean
> the whole audiofile is not immediately available in memory. Therefore,
> the result would somehow be equivalent to the
> '[readsf~]-in-an-upsampled-patch'  trick.

The problem with the '[readsf~]-in-an-upsampled-patch' approach is that
you cannot know how fast you can do it without interrupting audio. Also
you cannot really fine-tune it since you can only set it to a speed to
any power of two. 
Ideally, a threaded [soundfiler] would load the file as fas as possible
in the background without interfering with Pd's main process and then it
would output a bang when done.

Roman


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

Re: [PD] Interruption of audio / Loading sound into array

[Thomas Grill]

Hi all,
have you had a look at this:
http://grh.mur.at/software/sndfiler.html
It used to work for me, although i haven't tried for a long time (that  
is, with current pd versions)

gr~~~

Am 04.11.2011 um 11:26 schrieb katja:


By coincidence I noticed an svn commit access request from Damian
Stewart, back in 2008, where he proposes to 'implement multithreaded
[soundfiler] read'
(http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html).
What has become of this? Is there any code from this project?

[readsf~] and writesf~] are threaded, they operate in a child process.
I guess it could not be otherwise? Because they do not intend to read
all samples at once. Looking at the code in d_soundfile.c, I can
understand why the whole of Pd should not be multithreaded. It is a
lot of overhead. But [soundfiler~] read is another exceptional case
indeed, it needs carefully scheduled loading if it is not to cause
buffer underruns elsewhere. Such loading in portions would also mean
the whole audiofile is not immediately available in memory. Therefore,
the result would somehow be equivalent to the
'[readsf~]-in-an-upsampled-patch'  trick. But, like Charles pointed
out, it is not trivial to find an optimum. I agree Pd should better do
this in C.

Katja

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



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

Re: [PD] Interruption of audio / Loading sound into array

[katja]

By coincidence I noticed an svn commit access request from Damian
Stewart, back in 2008, where he proposes to 'implement multithreaded
[soundfiler] read'
(http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html).
What has become of this? Is there any code from this project?

[readsf~] and writesf~] are threaded, they operate in a child process.
I guess it could not be otherwise? Because they do not intend to read
all samples at once. Looking at the code in d_soundfile.c, I can
understand why the whole of Pd should not be multithreaded. It is a
lot of overhead. But [soundfiler~] read is another exceptional case
indeed, it needs carefully scheduled loading if it is not to cause
buffer underruns elsewhere. Such loading in portions would also mean
the whole audiofile is not immediately available in memory. Therefore,
the result would somehow be equivalent to the
'[readsf~]-in-an-upsampled-patch'  trick. But, like Charles pointed
out, it is not trivial to find an optimum. I agree Pd should better do
this in C.

Katja

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

Re: [PD] Interruption of audio / Loading sound into array

[João Pais]

because of the things explained by Mathieu and HC, it will never be  
perfect. but there are some small solutions that can try to avoid the  
problem:


- don't have any graphical display: put your array in a [table] instead of  
an array, or in a subpatch where it's not showing
- load all samples before you start doing audio, if possible (there's lots  
of memory available these days)


Or any smarter techniques involving upsampling etc, as said by others.

João



Hi,

This might just be a graphics related problem. Just disable the  
graphical representation of the arrays (I'm not in front of Pd right now  
but If I remeber well, it's just a matter of clicking on the arrays and  
unchecking the "graph on parent" box). I had the very same problem under  
Win XP, it solved everything.


Hope this helps.

D.S


http://www.flickr.com/photos/schafferdavid/
http://audioblog.arteradio.com/David_Schaffer/


From: i...@miamiwave.com
To: sebastian.han...@gmx.de; pd-list@iem.at
Date: Mon, 31 Oct 2011 19:24:20 +0100
Subject: Re: [PD] Interruption of audio / Loading sound into array

[soundfiler] will always interrupt the audio stream.

What I have done before was to stream the soundfile into a table with
[readsf~]. You can upsample the subpatch with [block~] or [switch~] so  
it

reads faster than realtime.

Ingo



> -Ursprüngliche Nachricht-
> Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im  
Auftrag von

> Sebastian Hanusa
> Gesendet: Montag, 31. Oktober 2011 18:37
> An: pd-list@iem.at
> Betreff: [PD] Interruption of audio / Loading sound into array
>
> Dear List!
>
> I have a problem, where hope the solution is so easy as it is
> complicated for me to find a solution:
>
> When I am loading a soundfile (about one 30 seconds, stereo, .aif,
> 16bit/44100Hz) to an array and simultaneously I have a quite simple
> audio prozess like replaying a second soundfile with [readsf] + for
> example a delay and a bandbass I get in the moment of loading to the
> array a dropout of the audio stream.
>
> I tryed to switch off the patch within the array for the moment of
> loading - but I get the same result.
>
> Is there a way to avoid this dropout?
>
> I am working with pd_extended 0.42.5 on a MacBook 2 GHz Intel Core 2
> Duo, OS X 10.5.8
>
> Thanks a lot for any help and with best regards,
>
> Sebastian



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





--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jmmmp...@googlemail.com | skype: jmmmpjmmmp

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

Re: [PD] how to capture window-related mouse-events when toxy is discontinued?

[katja]

On Fri, Nov 4, 2011 at 3:46 AM, Jonathan Wilkes  wrote:

> Oh, wow-- lines, polygons, and text of scalars get deleted and recreated 
> every time they
> get moved.  This is what gets sent to the GUI for every motion event when 
> dragging a
> scalar (in run mode here):
>
> .x291cf70.c delete curve291f238
> .x291cf70.c delete curve291f238
> .x291cf70.c create polygon\
> 217 175\
> 227 175\
> 227 185\
> 217 185\
> -width 1.00\
> -fill #ff -outline #00\
> -tags curve291f238
> .x291cf70.c create line\
> 172 130\
> 272 130\
> 272 230\
> 172 230\
> 172 130\
> -width 1.00\
> -fill #00\
> -tags curve291f238
>
> I imagine if this were changed to tag the entire scalar and move it by tag,
> it would improve the performance quite a bit.

Possibly the idea behind the polygons was more to manipulate (or
visually represent) the character of sound by altering a polygon's
shape. See help browser >> 4.data.structures/07.sequencer.pd. Then it
is obvious that a polygon must be redrawn everytime. In my view,
changing shapes is much more imaginative than dragging fixed shapes
around. But in live performance, it is easier to hit a 50*50 pix
square on a touch screen and drag it around, than trying to pick a
polygon's minuscule corner with a mouse.

Katja

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

Re: [PD] how to capture window-related mouse-events when toxy is discontinued?

[João Pais]

I imagine if this were changed to tag the entire scalar and move it by  
tag,

it would improve the performance quite a bit.


that would be a revolution :)

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

Re: [PD] expr alternative

[Olivier B]

2011/11/4 i go bananas 

> apple just rang me.
>
> as andy predicted, they are still being highly cagey and will not give a
> yes/no answer to me.  grrr.
>
> however, what they told me, was to go part of the way through developer
> registration, so i could read the "ios_program_standard_agreement", in
> which case i would "find what i need to know".
>
> here's the clause that pertains to FOSS licensing:
>
> "3.3.20If Your Application includes any FOSS, You agree to comply with
> all applicable FOSS licensing terms. You also agree not to use any FOSS in
> the development of Your Application in such a way that would cause the
> non-FOSS portions of the Apple Software to be subject to any FOSS licensing
> terms or obligations."
>
>
> so, to my simple mind, it appears that LGPL IS allowed in iOS
> applications, as long as you make the source available in a way that is
> LGPL compliant.
>
> the only thing that bothers me, is this section of the iOS agreement:
>
> "7.1Delivery of Freely Available Licensed Applications via the App
> Store; Certificates
> If Your Application qualifies as a Licensed Application, it is eligible
> for delivery to end-users via the App Store by Apple and/or an Apple
> Subsidiary. If You would like Apple and/or an Apple Subsidiary to deliver
> Your Licensed Application or authorize additional content, functionality or
> services You make available in Your Licensed Application through the use of
> the In App Purchase API to end-users for free (no charge) via the App
> Store, then You appoint Apple and Apple Subsidiaries as Your legal agent
> pursuant to the terms of Schedule 1, for Licensed Applications designated
> by You as free of charge applications.
>
> If Your Application qualifies as a Licensed Application and You intend to
> charge end-users a fee of any kind for Your Licensed Application or within
> Your Licensed Application through the use of the In App Purchase API, You
> must enter into a separate agreement (Schedule 2) with Apple and/or an
> Apple Subsidiary before any such commercial distribution of Your Licensed
> Application may take place via the App Store or before any such commercial
> delivery of additional content, functionality or services for which you
> charge end-users a fee may be authorized through the use of the In App
> Purchase API in Your Licensed Application."
>
> i'm not sure if those clauses have any effect on using LGPL code?
>
> Anyway, this is the information i have so far, and i thought i should
> share it.
>
> It appears to me that if Mr Yadegari and IRCAM are willing to license expr
> under the LGPL, then there's a good chance that the 'full' vanilla
> distribution would be allowed in iOS applications.
>
> it's very hard for me to continue looking into this matter, because there
> are some fairly significant moral issues and despite my laughing at people
> a little bit, i actually do think these things through, and it's a bit of a
> difficult situation.
>
> if people are following this issue, and just not saying anything, then it
> would help to get a clearer consensus of the 'community view' here, as i
> feel very uncomfortable about pushing this issue if i am going against the
> general consensus.
>
> to outline so far, there seem to be 3 main options:
>
> 1) leave expr as GPL
> 2) take up Mr Yadegari's offer to re-license under the LGPL
> 3) raise some money or incentive for Mr Yadegari to re-write expr code to
> be BSD compliant


3) I offer 10€... who's next ?



>
>
>
>
>
>
> On Fri, Nov 4, 2011 at 8:50 AM, Olivier B wrote:
>
>> 2011/11/2 Jonathan Wilkes 
>>
>>> >
>>> >From: Olivier B 
>>> >To: i go bananas 
>>> >Cc: PD-List 
>>> >Sent: Wednesday, November 2, 2011 8:01 AM
>>> >Subject: Re: [PD] expr alternative
>>> >
>>> >
>>> >Hi list...
>>> >
>>> >Just to say that, even if my patchs are published under GPL, as I
>>> definitely need my lines to be straight (or not aliased), I would prefer
>>> [expr] to be under BSD, like Pd-Vanilla is...
>>>
>>> What does the license have to do with straight lines and aliasing?
>>>
>>
>> Sorry list...
>>
>> I've certainly done a private joke only to myself... :-/
>> I just wanted to say that I like my Pd patches to be tidy... to have
>> their lines (or wires, I don't know the word used in english) perfectly
>> straight...
>> And for the same reason, it disturbs me to know that Pd-vanilla doesn't
>> offers the same license for all of its code... it makes disorder...
>> (but don't worry for me... every day, I'm getting better (damed, how it's
>> hard to try to make humor in a foreign language :-p ) )
>>
>> Cheers...
>>
>> 01ivier...
>>
>>
>>>
>>>
>>> -Jonathan
>>>
>>>
>>> >
>>> >Cheers...
>>> >
>>> >01ivier
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >2011/10/31 i go bananas 
>>> >
>>> >that's what i have just asked about.
>>> >>
>>> >>if you read back about halfway up the thread, max posted a mail saying
>>> that IRCAM are willing to change the license to LGPL.
>>> >>
>>> 

Re: [PD] Interruption of audio / Loading sound into array

[Charles Goyard]

Hi Hans,

Hans-Christoph Steiner wrote:
> Threading is not the only way to do concurrency.  Think of all of
> those objects in your patch, they are all running in parallel.

Yes, there's other ways than threading. ligthttpd and HAProxy are good
examples of monolithic state machine that can serve thousands of
requests per second. But in some respect, they are much more simple
projects than pd.

>From HAProxy "design choices"
===
HAProxy implements an event-driven, single-process model which enables
support for very high number of simultaneous connections at very high
speeds. Multi-process or multi-threaded models can rarely cope with
thousands of connections because of memory limits, system scheduler
limits, and lock contention everywhere. Event-driven models do not have
these problems because implementing all the tasks in user-space allows a
finer resource and time management. The down side is that those programs
generally don't scale well on multi-processor systems. That's the reason
why they must be optimized to get the most work done from every CPU
cycle.
===

The big difference is that you don't care is HAProxy if something takes
10us more.

In pd, a object like soundfiler blocks everybody else *long enough* so
you can ear it, *unless * you do the hard part, that is, time slicing.

My point is that it's really really hard to write solid threaded code
(that surely is a reason for pd being monoprocess in the first place).
So I find it strange that pd lets it to the user. Yes, having a 4-core
CPU and getting clicks in audio when you load a sample in an array is
hard to swallow in 2011 ;).

> And you had to do nothing to make sure that they run in parallel,
> don't block each other, sync up, etc.

That's the point of the discussion. A single threaded state machine is
not a multi-threaded process, where time-splicing occurs at the kernel
level.

Ok, so now I'm just complaining, and I can't write a threaded audio
engine just yet... So, fork() it ;).


-- 
Charlot

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

Re: [PD] symbol2list leading zero

[Roman Haefeli]

On Thu, 2011-11-03 at 17:54 -0400, Mathieu Bouchard wrote:
> Le 2011-11-03 à 21:09:00, Roman Haefeli a écrit :
> 
> > And it does not make so much sense to compare Pd/Max to anything outside 
> > of Pd/Max.
> 
> Why ?

You said "(as it is like with any string-splitter outside of pd/max)". I
should have said it more precisely: It doesn't make sense to compare
Pd/Max with anything outside of Pd/Max regarding string-splitting,
because 'just' splitting symbols (without the implicit conversion to
float for number-like symbols) is not very practical in the Pd/World.

Roman



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

Re: [PD] expr alternative

[i go bananas]

apple just rang me.

as andy predicted, they are still being highly cagey and will not give a
yes/no answer to me.  grrr.

however, what they told me, was to go part of the way through developer
registration, so i could read the "ios_program_standard_agreement", in
which case i would "find what i need to know".

here's the clause that pertains to FOSS licensing:

"3.3.20If Your Application includes any FOSS, You agree to comply with
all applicable FOSS licensing terms. You also agree not to use any FOSS in
the development of Your Application in such a way that would cause the
non-FOSS portions of the Apple Software to be subject to any FOSS licensing
terms or obligations."


so, to my simple mind, it appears that LGPL IS allowed in iOS applications,
as long as you make the source available in a way that is LGPL compliant.

the only thing that bothers me, is this section of the iOS agreement:

"7.1Delivery of Freely Available Licensed Applications via the App
Store; Certificates
If Your Application qualifies as a Licensed Application, it is eligible for
delivery to end-users via the App Store by Apple and/or an Apple
Subsidiary. If You would like Apple and/or an Apple Subsidiary to deliver
Your Licensed Application or authorize additional content, functionality or
services You make available in Your Licensed Application through the use of
the In App Purchase API to end-users for free (no charge) via the App
Store, then You appoint Apple and Apple Subsidiaries as Your legal agent
pursuant to the terms of Schedule 1, for Licensed Applications designated
by You as free of charge applications.

If Your Application qualifies as a Licensed Application and You intend to
charge end-users a fee of any kind for Your Licensed Application or within
Your Licensed Application through the use of the In App Purchase API, You
must enter into a separate agreement (Schedule 2) with Apple and/or an
Apple Subsidiary before any such commercial distribution of Your Licensed
Application may take place via the App Store or before any such commercial
delivery of additional content, functionality or services for which you
charge end-users a fee may be authorized through the use of the In App
Purchase API in Your Licensed Application."

i'm not sure if those clauses have any effect on using LGPL code?

Anyway, this is the information i have so far, and i thought i should share
it.

It appears to me that if Mr Yadegari and IRCAM are willing to license expr
under the LGPL, then there's a good chance that the 'full' vanilla
distribution would be allowed in iOS applications.

it's very hard for me to continue looking into this matter, because there
are some fairly significant moral issues and despite my laughing at people
a little bit, i actually do think these things through, and it's a bit of a
difficult situation.

if people are following this issue, and just not saying anything, then it
would help to get a clearer consensus of the 'community view' here, as i
feel very uncomfortable about pushing this issue if i am going against the
general consensus.

to outline so far, there seem to be 3 main options:

1) leave expr as GPL
2) take up Mr Yadegari's offer to re-license under the LGPL
3) raise some money or incentive for Mr Yadegari to re-write expr code to
be BSD compliant





On Fri, Nov 4, 2011 at 8:50 AM, Olivier B  wrote:

> 2011/11/2 Jonathan Wilkes 
>
>> >
>> >From: Olivier B 
>> >To: i go bananas 
>> >Cc: PD-List 
>> >Sent: Wednesday, November 2, 2011 8:01 AM
>> >Subject: Re: [PD] expr alternative
>> >
>> >
>> >Hi list...
>> >
>> >Just to say that, even if my patchs are published under GPL, as I
>> definitely need my lines to be straight (or not aliased), I would prefer
>> [expr] to be under BSD, like Pd-Vanilla is...
>>
>> What does the license have to do with straight lines and aliasing?
>>
>
> Sorry list...
>
> I've certainly done a private joke only to myself... :-/
> I just wanted to say that I like my Pd patches to be tidy... to have their
> lines (or wires, I don't know the word used in english) perfectly
> straight...
> And for the same reason, it disturbs me to know that Pd-vanilla doesn't
> offers the same license for all of its code... it makes disorder...
> (but don't worry for me... every day, I'm getting better (damed, how it's
> hard to try to make humor in a foreign language :-p ) )
>
> Cheers...
>
> 01ivier...
>
>
>>
>>
>> -Jonathan
>>
>>
>> >
>> >Cheers...
>> >
>> >01ivier
>> >
>> >
>> >
>> >
>> >
>> >
>> >2011/10/31 i go bananas 
>> >
>> >that's what i have just asked about.
>> >>
>> >>if you read back about halfway up the thread, max posted a mail saying
>> that IRCAM are willing to change the license to LGPL.
>> >>
>> >>so i'm now wondering, that of course it is a hassle to contact all the
>> original authors, but if none of them have moral views against BSD, then
>> maybe that would be an easier course of action that code rewrite.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>O