Re: [PD] libpd separating gui from core

[Peter Brinkmann]

On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic  wrote:

> The reason why I believe combining all of these will not be feasible is
> because in one of my recent conversations with Miller (and Miller please
> correct me if I somehow misremember here) he expressed his belief any
> project that exceeds N lines of code which I believe in this case it was
> something like 1, it becomes unmaintainable and dies.
>
That's why separating the GUI from the audio engine is so important. I sort
of agree that 1 lines of irreducible GUI+audio code would probably be
unmaintainable. On the other hand, 5000 lines of audio code plus 5000 lines
of GUI code, communicating through a smallish, well-defined interface,
wouldn't be a problem at all.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Peter Brinkmann]

Late to the party, but here are a few thoughts on the topics that have come
up:

1. Pd and concurrency: Audio processing must be separate from user
interaction. If you want decent latency, you need to do your audio
processing on a real-time thread. On the other hand, the GUI cannot be on a
real-time thread. So that's settled :P Moreover, processors haven't gotten
faster in a while, but you get more and more of them. So, to stay relevant
in the long run, we really want the option of multi-threaded audio
processing (bonus points if we manage to squeeze in GPU support). It's not
so much about existing patches that don't work well right now; it's more
about patches that have never been attempted.

1a. On a related note, it would also be helpful to have support for
hardware-specific optimizations such as vectorization. Right now, libpd
will run anywhere (which is great), but it's optimized nowhere (which
causes some users to abandon it after using it as a prototyping tool).

2. Multi-instance support must happen because that's what it takes to make
plugins with libpd. I'm sure we'll see a whole cottage industry of people
making Pd-based plugins when multiple instances of Pd become available. I'm
also pretty sure that this change would seriously interact with a
concurrency overhaul, and so those two should be done together.

3. I'm sort of losing track of all the stakeholders and their agendas.
Here's a rough list of players and their agendas as I see them:
  * Pd Vanilla (maintain backward compatibility so that existing works
won't bit-rot).
  * Pd Extended (get stuff done by adding lots of capabilities to Pd)
  * Pd-l2ork (get stuff done by adding lots of capabilities to Pd; not
sure how this relates to Pd Extended)
  * libpd (embed Pd into anything with a CPU)
  * Anyone else?

I don't think these agendas are necessarily at odds with one another.
Cheers,
 Peter




On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner wrote:

> I think Miller's  puredata is awesome. more than  20 years ago I wrote my
> own assembly routines as well as c++ for an analog devices 32 ch board for
> waterplant control software , but ended up using the factory drivers
> instead when they came out for this software
> http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html.
> reminds me more of reaktor than puredata. I  have a hard time
> comprehending reaktor stuff but things make so much more since using pd.
> I ought do dig into the programming part of pd . I read a lot of the code
> and it's kinda starting to sink in how to write an external, it's not quite
> like on the tip of my toungue yet though.
>
>
> On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes wrote:
>
>> On 02/24/2014 03:03 PM, Dan Wilcox wrote:
>>
>>> Exactly. If we can build a list of things that should/could be in the
>>> core, then we have a starting place to see if there is a way to work into
>>> into either vanilla or a wrapper like libpd.
>>>
>>
>> Let's just focus on a single feature-- "$@"-- and assume that there is
>> widespread desire for such a feature by most Pd users.
>>
>> How do we put this feature into a wrapper like libpd?  The only thing I
>> can think of is as part of a patch set that get applied to core Vanilla,
>> and that's hard to maintain.
>>
>> As for working stuff into Vanilla-- that's Miller's personal version of
>> Pd, and I've never once seen him state that it's the reference client, or
>> that it's at the top of any hierarchy.  All I've seen is passive-aggressive
>> statements from other devs on this list who say, "You'll have to ask Miller
>> if you want to get 'whatever' in Vanilla," when I ask about the kind of
>> issues you're talking about. Of course I can't be certain but I'd guess
>> that style of non-development is probably one of the biggest sources of
>> your frustration.
>>
>> But I really will help you implement whatever it is you think improves
>> sustainable development for Pd.  I really, really don't want to extract
>> patches from the 1000+ commits in Pd-l2ork (granted the core/non-graphical
>> changes would be fewer), but I'll help you do it if that's the path you
>> want to take.
>>
>> -Jonathan
>>
>>
>> ___
>> 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
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] New PdDroidParty version

[Peter Brinkmann]

Hello everybody,
If you're using the new version of PdDroidParty that Chris just published,
it would be great if you would let me know how it's working for you. (In
particular, how's the latency? Are input and output working without
glitches?) I'm pretty confident that the new latency tweaks are sound, but
it's brand new code and I'd like to hear how it's holding up in the wild.
Thanks,
 Peter



On Fri, May 31, 2013 at 10:59 AM, Chris McCormick wrote:

> Hi all,
>
> Just pushed a new version with Peter Brinkmann's latest latency tweaks.
> Seems pretty solid and subjectively much faster. Also bundled are a bunch
> of tweaks and fixes from Antoine Rousseau.
>
> http://droidparty.net/
>
> Have fun!
>
> Cheers,
>
> Chris.
>
> --
> http://mccormick.cx/
>
> __**_
> 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] libpd netreceive

[Peter Brinkmann]

Hi Billy,
Use the latest version. I don't think we've had any regressions.
 Peter



On Sun, Jan 20, 2013 at 9:52 PM, Billy Stiltner wrote:

> Peter while you are in here,  i'm wondering about using the latest
> libpd on linux, would it be better to use the old code or the latest?
> is there anything that doesn't work that didn't work  in the  previous
> versions?
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd netreceive

[Peter Brinkmann]

Hi Thomas,
I have to admit that I didn't realize that netreceive requires an extra
polling step. So, I'm afraid that netreceive is currently broken.

The question is what to do about this. I took a quick look at
sys_domicrosleep and didn't immediately see how it works. I wouldn't mind
integrating it into libpd somehow, but I want to be sure that there won't
be any weird side effects. This seems slightly off-topic for pd-list. Shall
we talk about this on pd-dev?
Cheers,
 Peter



On Sun, Jan 20, 2013 at 6:42 PM, Thomas Grill  wrote:

> Hi all,
> i am new to libpd and i have run into problems using netreceive on ios 5.1.
> While netsend works perfectly, netreceive doesn't work at all. Senders can
> connect to the receiving socket, but netreceive wouldn't spit out any data.
> Looking at the code, it seems to me that the polling of the net sockets
> (done in plain Pure Data in s_inter.c / sys_domicrosleep) is not called in
> libpd at all. I also couldn't find a different place where this is done.
> Does that mean that libpd doesn't currently service incoming socket data?
>
>
> Thanks for clarification, all the best,
> gr~~~
>
> --
> Thomas Grill
> http://g.org
>
> ___
> 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] ... and the battle with IT begins

[Peter Brinkmann]

I see you have met Mordac, Preventer of Information Services
(http://search.dilbert.com/comic/Mordac%20The%20Preventer). The
message you received is clearly meant to demoralize and intimidate,
what with the condescension ("obvious reasons" --- this is not obvious
at all), bogus jargon ("production environment" --- sounds really
impressive but doesn't apply to your setting), and gratuitous use of
the passive voice ("will be installed" --- act of God, I suppose).
Sadly, I've encountered this kind of attitude at several universities.
Good luck,
  Peter


On Thu, Sep 13, 2012 at 1:14 PM, m.e.grimm  wrote:
> my rant is as follows
>
> when making a request to have pd-extended 0.43.1 installed on the
> teaching station i get:
>
> "Mark:
>
> For obvious reasons, we won't install a beta release of software in a
> production environment.
>
> The current latest production release will be installed."
>
> which im fine with 042.5 but this is just more annoying than anything else.
>
> am I alone or do others on this list in Universities battle with IT on
> a daily basis? i am suspecting im not alone.
>
> is it the word "BETA" that is so bothersome? what is a "production
> environment"? am i not producing something?
>
>
> --
> 
> m.e.grimm | m.f.a | ed.m.
> megr...@gmail.com
> _
>
> ___
> 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] PD on Playstation 3?

[Peter Brinkmann]

Hi Filippo,
You may want to reach out to Kent Jolly. He gave a talk on the use of
Pd at Electronic Arts last year. He's also interested in libpd.

I'm not familiar with PS3 development, but the basic setup of libpd in
a new environment is always the same. Since libpd doesn't have any
dependencies, you can just drop it into your project (as long as you
have a C compiler, that is). Then you wire the process callback of
libpd into the audio components of your environment (if your audio
environment offers a callback-driven API like JACK or PortAudio, that
just takes a few lines of code).

The only part that requires thought is concurrency. Chances are that
the process method will be invoked on a separate thread, while control
messages will come from another thread. That requires some sort of
synchronization. The easiest way to do that is with mutex locks, but
there are other ways if you'd rather avoid locks. Feel free to refer
your developers to me if they have questions.
Cheers,
 Peter


On Sun, Aug 19, 2012 at 10:44 AM, Filippo Beck Peccoz  wrote:
> Hi Simon, thanks for the quick reply!
>
> ah, seems like not much has happened since then.. I'm pretty sure it is
> doable with lbpd (correct me if I am horribly wrong), but what would be
> great is to have someone show up saying "I've done it and it works!" so that
> I can convince our programmers to integrate PD ;)
>
> Filippo
>
>
> Filippo Beck Peccoz
> Game Audio
> www.fbpsound.com
> Twitter: @fbpsound
> Skype: fbpsound
> Mobile: +49-(0)1520-4004143
>
> On Aug 19, 2012, at 4:00 PM, Simon Wise wrote:
>
> On 19/08/12 18:38, Filippo Beck Peccoz wrote:
>
> Hi all,
>
>
> Now my question: does anyone have practical experience with porting PD to
> PS3? Does it run smoothly? Is it easy to do so?
>
>
> Any thoughts are greatly appreciated :)
>
>
> there was a discussion back a few years regarding this ...
>
> the archives show these threads:
>
> http://lists.puredata.info/pipermail/pd-list/2007-11/056300.html
>
> http://lists.puredata.info/pipermail/pd-list/2007-07/052174.html
>
> http://lists.puredata.info/pipermail/pd-list/2007-12/058006.html
>
> that was 5 years ago of course, but it was ported and used at that time, in
> house by Sony at least ... but that port was not released (most of Pd
> vanilla is not copyleft or GPL ... but rather a more liberal license ... so
> keeping the port closed is OK by the license).
>
> Simon
>
> ___
> 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
>

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

Re: [PD] Open midi files in PD Vanilla?

[Peter Brinkmann]

On Mon, Aug 13, 2012 at 10:51 PM, patrick  wrote:
>> (Or does libpd not load externals?)
>
>
> libpd is able to load an external, i have successfully used Gem.pd_linux
> with libpd as a standalone pd / Gem application.

That's great! Did you document your experiences anywhere? I get lots
of questions about Gem and libpd, and it would be great to have a
resource to point people to.

About libpd and externals, there was the licensing problem of the expr
family of externals (which has been resolved now, I think), but the
main goal was to keep libpd as small as possible. Even at its current
size, it's already pushing the memory budget of many games and mobile
applications.

Generally speaking, it's pretty straightforward to use externals with
libpd: If your platform supports dynamically loaded libraries, you can
build the external as usual and deploy it with your application; just
make sure that the location of the shared library is on libpd's search
path (deploying externals for Android currently requires an extra
step, but as soon as the new OpenSL version becomes official, that
will no longer be necessary).

If your platform doesn't support dynamic loading (iOS is the only case
I'm aware of), then you can just statically link the externals with
your app and explicitly call its setup function. Details are in the
libpd wiki:https://github.com/libpd/pd-for-ios/wiki/ios
Hope this helps,
 Peter

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

Re: [PD] libPD and Unity status?

[Peter Brinkmann]

Hi Scott,
About dynamic patching with libpd, the topic came up at Pd Everywhere:
createdigitalnoise.com/discussion/867/webpd-reloaded

The upshot is that dynamic patching is done with Pd messages, and the
message passing mechanism of libpd supports this. There has been talk
of creating a dynamic patching library on top of libpd, but I don't
know the current state of this idea.
Cheers,
 Peter


On Sun, Aug 12, 2012 at 12:05 AM, Scott R. Looney
 wrote:
> hi Peter - i remember that post. having very recently come into game audio i
> got myself acquainted with middleware through FMOD, and immediately thought
> there should be a better way to do this. i've read the posts on the goal of
> separating the GUI from the code, and that's what i think should happen, but
> doing it in Unity Free is my focus. things like not being able to implement
> filtering in your audio unless you pay $1500 for Unity Pro is absurd.
>
> what i'm envisioning is TCP or event-based communication to an app that is
> using libPD. the app would have a GUI talking directly to libPD and
> outputting audio. vitally important to this would be the ability to
> dynamically create or instantiate patches or objects. i'm fairly certain
> this can be done in PD. can such a thing also be done with libPD?
>
> regarding using the separate app - ideally i want something that can be used
> for a variety of game engines, not just Unity. if we use libPD in a Unity
> project, then we'd either be forced to create the GUI in Unity or have
> separate communication with the GUI outside of Unity. i suppose that's
> possible but i'd have to consider whether it's more efficient or not.
>
> scott
>
> On Sat, Aug 11, 2012 at 4:56 PM, Peter Brinkmann
>  wrote:
>>
>> I hope that it won't be necessary to do this in two steps, prototyping
>> with Pd and deployment with libpd; that would mean discarding one of
>> the strengths of libpd (here's an old blog post on the matter:
>>
>> http://nettoyeur.noisepages.com/2011/02/libpd-workflow-prototyping-and-production/).
>> It would be great if somebody figured out how to integrate libpd into
>> Unity and then posted the code to GitHub. I'm still hoping that Henk
>> Boom will write the blog post that he hinted at a while ago.
>> Cheers,
>>  Peter
>>
>> On Sat, Aug 11, 2012 at 1:13 PM, Scott R. Looney 
>> wrote:
>> > i think the answer at the moment is not to use libPD when running Unity
>> > live
>> > in a prototyping designing fashion, but rather instead communicate
>> > messages
>> > via TCP to PD itself, and let PD do the work directly. then when
>> > building
>> > the iOS project, you adjust the code in Xcode to use libPD for the audio
>> > output. that's the tricky part. i think that could work for now. it
>> > becomes
>> > a lot more complex to set simple audio sources, but perhaps there could
>> > be a
>> > mixture going on. i'll probably take further discussion off list as it
>> > would
>> > not relate as much to PD but more to Unity.
>> >
>> > scott
>> >
>> >
>> > On Sat, Aug 11, 2012 at 8:50 AM, patrick  wrote:
>> >>
>> >> hi Scott,
>> >>
>> >> it's somewhat working for me on Windows, but only when using the
>> >> audio.clip.GetData / SetData. right now i am trying to use the
>> >> OnAudioFilterRead() but it's glitchy (i can hear pd running but it's
>> >> mostly
>> >> noise).
>> >>
>> >> you can see an attempt here:
>> >> http://goo.gl/BWdo4
>> >>
>> >> here's my github:
>> >> https://github.com/patricksebastien/libpd4unity
>> >>
>> >> OnAudioFilterRead():
>> >> http://goo.gl/WE2Xx
>> >>
>> >> keep us updated!
>> >>
>> >> ___
>> >> 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
>> >
>
>

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

Re: [PD] libPD and Unity status?

[Peter Brinkmann]

Hi everybody,
This is exciting stuff! It would be great if we could document all
Unity-related efforts in one place. I created a wiki page for this
purpose: https://github.com/libpd/libpd/wiki/Unity Feel free to update
this page if you have any insights to share.
Thanks,
 Peter


On Mon, Aug 13, 2012 at 10:56 PM, patrick  wrote:
> hi,
>
> i was able to use libpd inside Unity 3d Pro (at my job...), will update my
> github with the piece of code that did the trick for me.
>
> i guess with the free version of Unity the solution posted by Filippo is the
> (only?) way to go. but i think if you have the android license (was free for
> awhile) you can import DLL. need to test this.
>
> cheers
>
>
>
> ___
> 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] libPD and Unity status?

[Peter Brinkmann]

I hope that it won't be necessary to do this in two steps, prototyping
with Pd and deployment with libpd; that would mean discarding one of
the strengths of libpd (here's an old blog post on the matter:
http://nettoyeur.noisepages.com/2011/02/libpd-workflow-prototyping-and-production/).
It would be great if somebody figured out how to integrate libpd into
Unity and then posted the code to GitHub. I'm still hoping that Henk
Boom will write the blog post that he hinted at a while ago.
Cheers,
 Peter

On Sat, Aug 11, 2012 at 1:13 PM, Scott R. Looney  wrote:
> i think the answer at the moment is not to use libPD when running Unity live
> in a prototyping designing fashion, but rather instead communicate messages
> via TCP to PD itself, and let PD do the work directly. then when building
> the iOS project, you adjust the code in Xcode to use libPD for the audio
> output. that's the tricky part. i think that could work for now. it becomes
> a lot more complex to set simple audio sources, but perhaps there could be a
> mixture going on. i'll probably take further discussion off list as it would
> not relate as much to PD but more to Unity.
>
> scott
>
>
> On Sat, Aug 11, 2012 at 8:50 AM, patrick  wrote:
>>
>> hi Scott,
>>
>> it's somewhat working for me on Windows, but only when using the
>> audio.clip.GetData / SetData. right now i am trying to use the
>> OnAudioFilterRead() but it's glitchy (i can hear pd running but it's mostly
>> noise).
>>
>> you can see an attempt here:
>> http://goo.gl/BWdo4
>>
>> here's my github:
>> https://github.com/patricksebastien/libpd4unity
>>
>> OnAudioFilterRead():
>> http://goo.gl/WE2Xx
>>
>> keep us updated!
>>
>> ___
>> 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
>

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

Re: [PD] [PD-announce] pd 0.43-3 released

[Peter Brinkmann]

Hi Miller,
Thanks for including two libpd-related patches in Pd 0.43-3!  I merged
your changes into the (still experimental) opensl branch of libpd and
everything seems to be working nicely.  In particular, building and
deploying externals for Android is perfectly straightforward now.
Cheers,
 Peter

On Tue, Jul 3, 2012 at 5:11 PM, Miller Puckette  wrote:
> Hi all,
>
> Pd version 0.43-3 is available on http://crca.ucsd.edu/~msp/software.htm
> or via git from sourceforge:
> git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
>
> Main change from 0.43-2 is that MIDI input is improved on Mac and Windows.
>
> Also, I added a stub to future-proof Pd against a possible extension of the
> file format so that in the future there could be a way to set widths of
> boxes and stuff like that (and 0.43-3 would read those files and only complain
> once instead of complaining for pages.)
>
> I'm ready to start hacking on 0.44.  The most urgent thing seems to be for
> me to go back and work on the audio system (and perhaps tweak MIDI a bit
> more too).
>
> The thing I'm actually looking forward to doing is to extend textfiles and
> message boxes and data structures to be able to spit lists of atoms around
> much more flexibly than now.
>
> Also pd vanilla needs tilde objects to do interpolating signal snapshots,
> phase-syncable oscillators, and other stuff on that level, also likely
> to be a lot of fun.
>
> cheers
> Miller
>
> ___
> Pd-announce mailing list
> pd-annou...@iem.at
> http://lists.puredata.info/listinfo/pd-announce

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

Re: [PD] for ivo - and others - re:mu integration of PD with Unity 3.5?

[Peter Brinkmann]

Hi Scott,
The latest version of libpd includes basic C# bindings, and it looks
like we'll have full C# support soon.  I'm not familiar with Unity,
but I gather that C# bindings are a prerequisite for using libpd with
Unity.
Cheers,
 Peter


On Thu, May 3, 2012 at 8:46 PM, Scott R. Looney  wrote:
> hey PD listers, my question is about the use of the mu 1.00 tools from DISIS
> for use in PD. these tools allow integration of the Unity game engine with
> Max/MSP and potentially PD according to the authors.
>
> i downloaded the demo which is very Max-oriented. is there a plan or sketch
> or some way of setting up communication with PD instead?
>
> i'm also waiting for information on how to use libpd as the sound engine for
> a Unity project. the developer of the game Fract, Henk Boom, was supposed to
> detail some bit about this soon, but curious if anyone on the list has ever
> used PD with the Unity game engine...
>
> any advice appreciated...
>
> scott
>
>
> ___
> 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] [PD-dev] Filter design for iPhone

[Peter Brinkmann]

On Sat, Mar 24, 2012 at 5:20 AM, Ed Kelly  wrote:
> My mistake
>
>> Ah.
>> As often happens, as soon as I have pressed "send" and posted the
>> question, the answer pops out.
>> xb4 = xb4 - xb4 * xb4 * xb4 * 0.17f;
>>
>> is replaced by...
>>
>> xb4 = xb4 - xb4 * xb4 * xb4 * 0.01f;
>>
>> ...and it works.
>
> and then breaks again

Inf - Inf is NaN.  If the value of xb4 spirals out of control, that
may happen here.  That would also explain why it takes longer to fail
when you reduce the last factor.

>
> Gemnotes-0.1alpha: Live music notation for Pure Data
> http://sharktracks.co.uk/
> 
> From: Ed Kelly 
> To: Mathieu Bouchard 
> Cc: PD List ; Joe White ; pddev 
> Sent: Saturday, 24 March 2012, 8:47
> Subject: Re: [PD-dev] [PD] Filter design for iPhone
>
>>> I'm anxious to know what limit is reached in the coefficients of the
>>> filter that causes the undefined result (NaN).
>>
>>I haven't seen the code, but I just want to make you notice that adding
>> together -Infinity and +Infinity results in a NaN ; so does subtracting
>>two infinities of the same sign.
>>
>>So, the NaN might happen when two expressions that are supposed to
>> partially cancel each other, happen to both overflow, in different
>> directions.
>>
>>There are various possible causes for NaN, but with formulas that only
>> involve +, - and *, the possibilities are a lot more limited.
>
> Hmmm.
> I think that's why it puzzles me so. Can you see a / anywhere here?
>
>   while (n--) {
>     i1=(*in++);
>     fc1 = (*fc++);
>     res1 = (*res++);
>     q = 1.0f - fc1;
>     p = fc1 + 0.8f * fc1 * q;
>     fcoeff = p + p - 1.0f;
>     q = res1 * (1.0f + 0.5f * q * (1.0f - q + 5.6f * q * q));
>     i1 -= q * xb4;
>     t1 = xb1;
>     xb1 = (i1 + xb0) * p - xb1 * fcoeff;
>     t2 = xb2;
>     xb2 = (xb1 + t1) * p - xb2 * fcoeff;
>     t1 = xb3;
>     xb3 = (xb2 + t2) * p - xb3 * fcoeff;
>     xb4 = (xb3 + t1) * p - xb4 * fcoeff;
>     xb4 = xb4 - xb4 * xb4 * xb4 * 0.17f;
>     xb0 = i1;
>     *out++ = xb4;
>  }
>
> No reciprocals, no divisions, just +,-,*.
> I cannot help thinking I must be reaching a "limit" in the calculus sense...
>
> Ed
>
>
>
>
> __
> | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC
>
>
> ___
> Pd-dev mailing list
> pd-...@iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
>
>
>
> ___
> 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] [PD-dev] Filter design for iPhone

[Peter Brinkmann]

Hi Ed,
The attached files are just the Pd patch and abstractions.  We'll
probably need the entire app to get a sense of what's going wrong
here.
Cheers,
  Peter


On Thu, Mar 22, 2012 at 11:52 AM, Ed Kelly  wrote:
>>> [...]
>>> I will look at the RJDJ filters mentioned also. I would like not to have to
>>> worry about filters when programming libpd audio engines.
>
>>Absolutely.  If a patch works with Pd Vanilla, then it ought to work
>>with libpd.  Would you mind filing a bug report at GitHub, ideally
>>with a minimal example that reproduces the problem?
>>Thanks,
>>     Peter
> Sure, although this is ofxPd from Dan Wilcox, so I'm not sure what the 
> difference is between this and the iOS or Android versions.
>
> Best,
> Ed

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

Re: [PD] [PD-dev] Filter design for iPhone

[Peter Brinkmann]

On Wed, Mar 21, 2012 at 8:39 PM, Ed Kelly  wrote:
> [...]
> I will look at the RJDJ filters mentioned also. I would like not to have to
> worry about filters when programming libpd audio engines.

Absolutely.  If a patch works with Pd Vanilla, then it ought to work
with libpd.  Would you mind filing a bug report at GitHub, ideally
with a minimal example that reproduces the problem?
Thanks,
 Peter

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

Re: [PD] Making Musical Apps: a book about libpd

[Peter Brinkmann]

I appreciate your reply, Mathieu.  I'm feeling better now.

On Thu, Mar 8, 2012 at 7:40 PM, Mathieu Bouchard  wrote:
> Le 2012-03-08 à 18:36:00, Peter Brinkmann a écrit :
>
>
>> Shawn and I accidentally crossed wires here --- Shawn didn't know that I
>> had already sent a message to Pd-Announce, and I didn't know that Shawn
>> would be posting to Pd-list.  We will coordinate better in the future, and
>> we apologize for the duplication. Sorry about the spammy aftertaste,
>
>
> I don't think that there has been any real problem with the way that it's
> been announced. I mean, it's not like you put a cronjob for it, or wrote any
> kind of false representation, or advertised random unrelated products.
>
> So, I don't think that you need to say you're sorry, nor to be sorry at all.
> Think of all the times that someone replied to a mail to both pd-list and
> pd-announce, which causes triplicata to anyone subscribed to both, and I
> don't think that anyone ever expressed an emotional response about it on the
> list !
>
>  __
> | 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] Making Musical Apps: a book about libpd

[Peter Brinkmann]

Dear List,
Shawn and I accidentally crossed wires here --- Shawn didn't know that
I had already sent a message to Pd-Announce, and I didn't know that
Shawn would be posting to Pd-list.  We will coordinate better in the
future, and we apologize for the duplication.
Sorry about the spammy aftertaste,
Peter

On Thu, Mar 8, 2012 at 6:18 PM, ALAN BROOKER  wrote:
> the f bomb...really? telling the guy to f*ck off..what? really ?
>
> Unacceptable.
>
>
> On Thu, Mar 8, 2012 at 10:49 PM, Martin Dupras  wrote:
>> I think that's a bit uncalled for. It's not spam, the book is entirely
>> relevant to the PD community since it centres on libpd, and the target
>> audience for the book is very much similar to the subscriber base for
>> this list.
>>
>> I don't see how that would be any different than advertising a concert
>> for which you would have to pay an entrance fee of a workshop where
>> you would need to pay to attend.
>>
>> - martin
>>
>>
>> On 8 March 2012 22:40, Julian Brooks  wrote:
>>> Look, I'm sorry.  I've attempted to ignore this...
>>>
>>> Fuck off.
>>>
>>> Spam merchant.
>>>
>>> There, said/done it.
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>> On 8 March 2012 20:17, Shawn Wallace  wrote:
>>>>
>>>> Hi all:
>>>>
>>>> Peter Kirn over at createdigitalmusic.com has a great review, interview
>>>> and excerpt of the new O'Reilly book "Making Musical Apps" by Peter
>>>> Brinkmann:
>>>>
>>>>
>>>>  http://createdigitalmusic.com/2012/03/pd-everywhere-free-libpd-gets-a-new-site-new-book-on-making-mobile-music-apps/
>>>>
>>>> I've always thought that Pure Data on mobile devices (with the touchscreen
>>>> and all the sensors) was a killer app.
>>>>
>>>> --Shawn
>>>>
>>>> ---
>>>> Shawn Wallace
>>>> O'Reilly Media
>>>> (401) 835-7550 cell
>>>> swall...@oreilly.com
>>>> www.fluxly.com
>>>> follow @fluxly
>>>>
>>>>
>>>> ___
>>>> 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
>>>
>>
>> ___
>> 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

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

[PD] netsend~ for libpd

[Peter Brinkmann]

On Sun, Mar 4, 2012 at 9:04 AM, Jeppi Jeppi  wrote:
> Hi people!
> well this is a feature request...I see the netsend~/netreceive~ objects
> from http://www.nullmedium.de/dev/netsend~/ are not included in the
> pd-extended release. They are *super* useful and I would like to know if
> there is any replacement to send audio streams through a network (fast,not a
> webcast/icecast broadcast scheme).
> Indeed, I would like to have them included in libpd...how should I proceed
> to do that?

Easy --- simply persuade Miller to add them to Pd Vanilla ;)

But seriously, libpd itself only tracks Pd Vanilla, and it doesn't
even compile the standard externals (e.g., fiddle~) into the core
binary.  (The standard externals are packaged with libpd, though, and
there's support for using them if you need to.)

Generally speaking, externals are less important when working with
libpd because it's frequently easier to implement the desired
functionality outside of Pd.  If you really want an external, then for
most platforms you can just deploy it in the usual way, build a shared
library and add the location of the shared object to libpd's search
path.  The only exception is iOS because it doesn't allow dynamic
loading of externals.  You'll have to bake the external into the
binary of your app instead.
Cheers,
    Peter

PS: Shameless plug: My book
(http://shop.oreilly.com/product/0636920022503.do) explains how to use
externals with iOS.

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

Re: [PD] [PD-announce] libpd, the book!

[Peter Brinkmann]

Thanks for the kind words, everybody!

About prerequisites, you will need to know the basics of Java or
Objective-C, e.g., basic syntax as well as terms like class, object,
method, and inheritance.  I'm also assuming that readers have some
basic knowledge of Android or iOS development, as well as a working
development setup.  If you know how to write simple apps for Android
or iOS, then you're ready to tackle this book.
Cheers,
 Peter


On Sat, Feb 25, 2012 at 2:57 AM, Ichabod  wrote:
> I see the table of contents lists a chapter called "Prerequisites." What
> exactly are the prerequisites in terms of knowledge of programming
> languages?
>
> Thanks,
> Stefán
>
> ___
> Pd-announce mailing list
> pd-annou...@iem.at
> http://lists.puredata.info/listinfo/pd-announce
>

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

[PD] [PD-announce] libpd, the book!

[Peter Brinkmann]

Hi,
I'm happy to announce the release of my book on mobile audio
development with libpd:
http://shop.oreilly.com/product/0636920022503.do

The ebook version is available now; printed copies will be available
from amazon.com next week.
Cheers,
 Peter

___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce

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

Re: [PD] Thoughts in conclusion of the 4th Pure Data Convention

[Peter Brinkmann]

Some random thoughts on various topics that have come up so far:

* Being afraid of Pd: Usability experts like to talk about things like
discoverability and constraints, and most users have been taught to
expect user interfaces that tell them what to do.  Pd doesn't do any
of that.  It greets you with a blank canvas and no indication what to
do next.  Now, I happen to believe that that's the right foundation
for creative work, but a lot of people are freaked out by the lack of
guidance.

* Pd vs Max/MSP: My impression is that many serious users of Max/MSP
feel that the slightly smoother user interface is worth the cost of
the license.  An overhaul of the UI would help Pd a lot, I think.

* Pd vs Processing/openFrameworks: No conflict here.  In fact, they
complement one another and might be taught together, now that libpd
can be integrated into both Processing and openFrameworks.

I believe that libpd will make a big difference, in several ways.
More than any other package I know of, it brings audio synthesis into
the mobile realm.  Moreover, real-time audio synthesis can now be
packaged and deployed almost like static media files, and that opens
up possibilities that weren't available before.  Also, we're already
seeing the emergence of alternative GUIs for Pd (in the form of Chris
McCormick's PdDroidParty and Dan Wilcox's PdParty) that are based on
libpd.

It's already looking promising.  If we manage to solve a few problems
that we've been talking about on Pd-Dev (better support for building
VST plugins and such with Pd, building a new GUI), then I'm confident
that Pd will attract plenty of new users going forward.
Cheers,
 Peter


On Thu, Feb 9, 2012 at 2:43 PM, Jonathan Wilkes  wrote:
> I'd like to hear more details about what terrifies them with Pd.
>
> As far as Linux-- I'm really liking Gnome 3 a lot.  You just shove the mouse 
> up in the top left
>
> corner of the screen (or hit the "Windows" key) and start typing the name of 
> the program you
>
> want to run, or even a keyword somewhat related to what you want.  So in 
> Wheezy "word" brings up
>
> abiword (and probably libreoffice writer if you have it installed), 
> dictionary, and some others;
>
> "install" brings up gdebi, synaptic, updater, add/remove software; "settings" 
> brings up system
>
> settings, email settings, network, and so on.  Takes only moments to learn 
> and is powerful once
>
> you learn it-- to bring up a terminal I click "-t-e" (which puts 
> "te" in the search
>
> window and brings up the icon for gnome terminal in the results) then enter 
> to run it.  Basically
>
> it's the GUI equivalent of tab completion.
>
> With a distro like Linux Mint you get a Gnome 3 desktop tweaked to look like 
> the common windows
>
> taskbar and up to date drivers for just about everything.
>
>
> -Jonathan
>
>
> - Original Message -
>> From: "Pagano, Patrick" 
>> To: Jonathan Wilkes ; Max ; 
>> PD list 
>> Cc:
>> Sent: Thursday, February 9, 2012 1:30 PM
>> Subject: RE: [PD] Thoughts in conclusion of the 4th Pure Data Convention
>>
>> My students are terrified of Pure data. They fear linux too. Out of ten grads
>> per year it used to be 1 or two would endeavor to learn GEM.
>> Now a few more are interested because of libpd for senior programming 
>> projects.
>> Currently in projection design I teach them pd, then Jitter then Isadora. 
>> They
>> have to pay their dues with PD first and other software with nice intuitive
>> PRICE TAGS come afterwards.
>>
>> pp
>>
>> -Original Message-
>> From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
>> Jonathan Wilkes
>> Sent: Thursday, February 09, 2012 1:23 PM
>> To: Max; PD list
>> Subject: Re: [PD] Thoughts in conclusion of the 4th Pure Data Convention
>>
>> There are still a lot of sticking points with Pd for new users-- someone
>> recently wrote the list asking where all the objects are that are listed in 
>> the
>> FLOSS manual.  At least
>>
>> some of those objects have to be downloaded/installed separately-- [pvoc~] is
>> listed
>>
>> under Pd extended but it's not included in it, nor is the relevant library
>> listed.
>>
>>
>> But even if pvoc~ doesn't create, how does the user know for _sure_ that
>> there isn't
>>
>> a pvoc~ binary living somewhere on their machine?  Pd is like those magnetic
>> words
>>
>> you put on a fridge to make poetry, but over time roommates come in and 
>> remove
>>
>> some of the words, and now you need your own blank magnet and pen and write 
>> the
>>
>> word and put it back on the fridge.  Or, you can put the word "import"
>> with some words
>>
>> that describe last place where you found the word-- many of those places have
>> helpful
>>
>> names that are the initials of the person who wrote them that you've never
>> met.  None
>>
>> of this is clearly documented btw, unless you ask on this listed and get a 
>> reply
>> in the
>>
>> time it would have taken to finish a patch if there had been clear 
>> documentation
>

Re: [PD] audio to arduino to PD, back to audio

[Peter Brinkmann]

Hi Onyx,
If low-fi ness and texture is what you're after, then you may want to
try bit-banging, i.e., sampling audio with digital pins, for a
resolution of one bit per sample.  That sounds crazy, but with a
little bit of low-pass filtering the output is surprisingly
recognizable.  It also improves your odds of staying within the
limitations of the hardware.

I built some audio toys around Arduino a few years ago and bit-banging
worked quite well for what I had in mind.  I would share the code, but
I believe I deleted it.
Cheers,
 Peter

On Mon, Nov 28, 2011 at 7:10 PM, Onyx Ashanti  wrote:
>
>
>
> An analog input on an Arduino is a poor Analog-to-Digital Convertor compared
> to audio ADCs.  Its 10-bit, and not more than 16kHz max (more like 4kHz)
> sampling rate.  Standard digital audio is 16-bit/44.1kHz.
>
> Then, having your Arduino read at 4kHz will require all of the CPU time, so
> it can't really do much else then.
>
> .hc
>
> thank you for getting back
> to me.
>
> How would it work though?  I am curious about the low fi ness and the
> texture it could bring to vocoding. I also would like to use voice
> modulations for synth sounds so high quality is not necessary. 4khz might be
> fine for the intended purpose; something better than r2d2 but not quite bad
> telephone connection. in between. all I need the arduino to do is sample the
> audio and send the data to pure data where I can deal with it there.  on the
> arduino, I just want the signal with no processing of any kind. possible?
>
>
>  _
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> 
>
> Man has survived hitherto because he was too ignorant to know how to realize
> his wishes.  Now that he can realize them, he must either change them, or
> perish.    -William Carlos Williams
>
>
>
> ___
> 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] Libpd on Android

[Peter Brinkmann]

The wiki is a collaborative effort, but I'm the one who wrote the most
recent update on Eclipse, and it's working for me in Eclipse 3.7, exactly as
stated.  You really shouldn't have to create any new projects because all
components of pd-for-android come with working Eclipse project
configurations.
Cheers,
 Peter


On Mon, Sep 19, 2011 at 8:56 PM, Pierre Massat  wrote:

> Hans, I tried using File>New...>Android project in Eclipse to import PdCore
> and the examples, and it worked! I'm using Eclipse 3.7. I guess it'd be nice
> to update the tutorial on gitorious, since the recommended way to get
> pd-for-android in Eclipse using Import doesn't work at all (at least for
> me). I don't know who is in charge of maintaining the wiki...
>
> Pierre
>
>
> 2011/9/19 Pierre Massat 
>
>> I did that, but i still get a ton of errors. In PdCore Eclipse seems
>> unable to import android.os.build in
>> /src/org.puredata.android.utils/Properties.java .
>>
>> I very confused, I thought it'd be easy to at least import PdCore...
>>
>> (To be perfectly honest i'm very new to Eclipse and to programming for
>> Android in general...)
>>
>> Thanks for your help...
>>
>> Pierre
>>
>>
>>
>> 2011/9/19 Hans-Christoph Steiner 
>>
>>>
>>> Missing gen/ folders are an Eclipse annoyance.  Try running Project ->
>>> Clean then building. If that doesn't work, then try creating a folder called
>>> 'gen' next to 'src', 'res', etc.
>>>
>>> .hc
>>>
>>>
>>> On Sep 19, 2011, at 1:47 PM, Pierre Massat wrote:
>>>
>>>  Hello,

 I wanted to try libpd and pd-for-android in Eclipse tonight, but nothing
 seems to work the way it should. The examples won"t work (Eclipse complains
 about missing /gen folders). I also tried importing PdDroidParty, but it
 won't work, and i don't know how to reference PdCore as a library for the
 project.
 I apologize if you consider this to be off-topic. I wanted to know who
 wrote libpd and pd-for-android, hoping that the author(s) would help me a
 little bit.

 Cheers,

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

>>>
>>>
>>>
>>> --**--**
>>> 
>>>
>>> Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.  It's
>>> about as sensible to say we declare war on night attacks and expect we're
>>> going to win that war.  We're not going to win the war on terrorism.
>>>  - retired U.S. Army general, William Odom
>>>
>>>
>>>
>>
>
> ___
> 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] Pd on Android

[Peter Brinkmann]

On Mon, Sep 5, 2011 at 7:46 PM, Chris McCormick  wrote:

> On Mon, Sep 05, 2011 at 06:20:26PM -0400, Hans-Christoph Steiner wrote:
> > [shell] is in ggee and [system] is in motex, both of those use the
> > Makefile Template, so they should be really easy to compile for Android.
> > How are you installing externals with PdDroidParty? It'd be nice to have
> > a simple, common folder to drop the whole library in, say something like
> > /sdcard/pd-externals.
>
> Hm, that's a good idea, and then the user could put the externals they want
> in that folder themselves. I guess I just use libpd's command to add that
> folder to Pd's path?
>

You'll probably need to copy the binaries to internal storage because
/sdcard is mounted as noexec.  I ran into that problem last year and it took
me ages to make sense of the error message...
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Wed, Aug 31, 2011 at 9:01 AM, Dan Wilcox  wrote:

>
> On Aug 31, 2011, at 8:45 AM, Peter Brinkmann wrote:
>
>
> On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox  wrote:
>
>> I think it's much simpler to just add a call to get/set the message limit,
>> say:
>>
>> int libpd_max_message_length();
>> void libpd_set_max_message_length(int length);
>>
>> This doesn't break any current code.
>>
>> Having to set a custom limit each time is far more tedious then just
>> setting it at startup.
>>
>
> Actually, breakage of current code is a feature as far as I am concerned
> because it makes people aware of the change, and it should be harmless
> because it's easy to fix.  The language bindings for Java and Objective-C
> actually became simpler when I updated them for the new version.
>
> I don't think the new signature of libpd_start_message is tedious, really.
> Essentially, I see two use cases: Either you know an a-priori limit on your
> message length, in which case there's the tiny extra effort of passing in
> the limit every time you start a message, or you don't have an a-priori
> limit, in which case you need to check the length before assembling a
> message anyway.
>
> Another aspect is API design.  One feature of a good API is that it's
> difficult to use incorrectly.  With a separate call for setting the message
> limit, people will forget that the limit is a consideration.  With the
> current solution, people will briefly contemplate the length of each message
> they start, which is a good thing.
>
>
> ... but you can simply return an error or print a message complaining when
> the message is too long. My whole point is that most people won't bother
> changing the limit and those that do will just pick a larger size with
> plenty of space anyway. It's too much work to bother setting it EACH and
> EVERY time. It's far LESS elegant, and dare I say intuitive. It seems like
> an unnecessary step. [eople that have problems will only run into this once,
> increase the max size, and then be fine. Why force them to compute a size
> manually each time when they could just be happily adding objects ... ?
>

Actually, I don't mean to make people compute the size every time  The
length parameter in libpd_start_message merely makes sure that you'll have
enough space for that many elements; the number of elements in the actual
message may be smaller.  If you know that your messages will never exceed a
certain length, then you can simply use that maximum length every time.  In
that situation, I would just wrap the call to libpd_start_message in a macro
or a convenience function to get exactly the effect that you want.



> In case, my wrapper will include max message size get/set functions and
> complain to cout when something is out of bounds.
>

And with the streaming API that you've built in C++, that's the right thing
to do:)
Cheers,
  Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Wed, Aug 31, 2011 at 11:27 AM, Peter Brinkmann <
peter.brinkm...@googlemail.com> wrote:

> On Wed, Aug 31, 2011 at 9:01 AM, Dan Wilcox  wrote:
>
>>
>> On Aug 31, 2011, at 8:45 AM, Peter Brinkmann wrote:
>>
>>
>> On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox  wrote:
>>
>>> I think it's much simpler to just add a call to get/set the message
>>> limit, say:
>>>
>>> int libpd_max_message_length();
>>> void libpd_set_max_message_length(int length);
>>>
>>> This doesn't break any current code.
>>>
>>> Having to set a custom limit each time is far more tedious then just
>>> setting it at startup.
>>>
>>
>> Actually, breakage of current code is a feature as far as I am concerned
>> because it makes people aware of the change, and it should be harmless
>> because it's easy to fix.  The language bindings for Java and Objective-C
>> actually became simpler when I updated them for the new version.
>>
>> I don't think the new signature of libpd_start_message is tedious,
>> really.  Essentially, I see two use cases: Either you know an a-priori limit
>> on your message length, in which case there's the tiny extra effort of
>> passing in the limit every time you start a message, or you don't have an
>> a-priori limit, in which case you need to check the length before assembling
>> a message anyway.
>>
>> Another aspect is API design.  One feature of a good API is that it's
>> difficult to use incorrectly.  With a separate call for setting the message
>> limit, people will forget that the limit is a consideration.  With the
>> current solution, people will briefly contemplate the length of each message
>> they start, which is a good thing.
>>
>>
>> ... but you can simply return an error or print a message complaining when
>> the message is too long. My whole point is that most people won't bother
>> changing the limit and those that do will just pick a larger size with
>> plenty of space anyway. It's too much work to bother setting it EACH and
>> EVERY time. It's far LESS elegant, and dare I say intuitive. It seems like
>> an unnecessary step. [eople that have problems will only run into this once,
>> increase the max size, and then be fine. Why force them to compute a size
>> manually each time when they could just be happily adding objects ... ?
>>
>
> Actually, I don't mean to make people compute the size every time  The
> length parameter in libpd_start_message merely makes sure that you'll have
> enough space for that many elements; the number of elements in the actual
> message may be smaller.  If you know that your messages will never exceed a
> certain length, then you can simply use that maximum length every time.  In
> that situation, I would just wrap the call to libpd_start_message in a macro
> or a convenience function to get exactly the effect that you want.
>

By the way, there's also a third way between specifying the max size every
time and creating a convenience function.  The start message function will
only allocate new memory if the requested size is larger than what was
requested before.  You can also say libpd_start_message(MAX_SIZE) right
after you initialize libpd, and then start all messages with
libpd_start_message(0), where 0 means that it'll just use whatever was
allocated before.  This is convenient, but it doesn't quite look right to
me, so I'd probably still go with convenience functions.
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox  wrote:

> I think it's much simpler to just add a call to get/set the message limit,
> say:
>
> int libpd_max_message_length();
> void libpd_set_max_message_length(int length);
>
> This doesn't break any current code.
>
> Having to set a custom limit each time is far more tedious then just
> setting it at startup.
>

Actually, breakage of current code is a feature as far as I am concerned
because it makes people aware of the change, and it should be harmless
because it's easy to fix.  The language bindings for Java and Objective-C
actually became simpler when I updated them for the new version.

I don't think the new signature of libpd_start_message is tedious, really.
Essentially, I see two use cases: Either you know an a-priori limit on your
message length, in which case there's the tiny extra effort of passing in
the limit every time you start a message, or you don't have an a-priori
limit, in which case you need to check the length before assembling a
message anyway.

Another aspect is API design.  One feature of a good API is that it's
difficult to use incorrectly.  With a separate call for setting the message
limit, people will forget that the limit is a consideration.  With the
current solution, people will briefly contemplate the length of each message
they start, which is a good thing.
Cheers,
 Peter



>
> On Aug 30, 2011, at 5:47 PM, Peter Brinkmann wrote:
>
>
>
> On Tue, Aug 30, 2011 at 3:44 PM, Mathieu Bouchard wrote:
>
>> On Tue, 30 Aug 2011, Peter Brinkmann wrote:
>>
>>  For the time being, I have something much simpler in mind: Just take the
>>> current call "int libpd_start_message(void)", which returns the current
>>> limit, and replace it with "int libpd_start_message(int length)", which
>>> takes a parameter indicating the length of the message and returns a nonzero
>>> error code if the length is too big.
>>>
>>
>> But this means that new libpd-using apps won't compile with old versions
>> of libpd AND vice-versa.
>>
>
> Well, the vast majority of users won't notice any difference at all because
> they're using the Android or iOS branch, which I'm updating as I go along.
> The only people who are affected by this are those who are using the C
> library directly, and I hope that they'll either be willing to update their
> code (which should be no more than a two-line change in most cases) or just
> stick to the current version, which will remain available via git.
>
> In any case, I think everybody understands that this is still a young
> library that needs to adapt as we gain a better understanding of how people
> are using it, and the cost of making a small incompatible change is a lot
> lower than choosing a suboptimal solution for compatibility with an earlier
> version.  This period of youthful innocence is coming to an end, though; the
> API has been quite stable for quite a while now, and I believe that it'll
> soon be time to declare it finished.  I want to take a critical look at
> every piece before we officially lock the API, and I won't be afraid to cut
> things that may turn out to be a burden in the long run.  (That's why I
> floated the idea of getting rid of the simple message assembly mechanism,
> but it looks like that's here to stay.)
> Cheers,
>  Peter
>
>
> 
> Dan Wilcox
> danomatika.com
> robotcowboy.com
>
>
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

Okay, I just pushed the latest version of libpd (including dynamic
allocation of the t_atom array for assembling list messages, i.e., no
a-priori limit of the message size).  I also updated the Android and iOS
branches as well as the wiki.
Cheers,
 Peter



On Tue, Aug 30, 2011 at 1:25 PM, Peter Brinkmann <
peter.brinkm...@googlemail.com> wrote:

>
>
> On Tue, Aug 30, 2011 at 12:51 PM, Mathieu Bouchard wrote:
>
>> On Tue, 30 Aug 2011, IOhannes m zmoelnig wrote:
>>
>>  why not simply resize the internal array as needed, starting with 32
>>> elements and doubling whenever the limit is reached?
>>>
>>
>> binbuf could be used for that, if the libc's realloc does in effect the
>> same thing. i think that this is the case with modern glibc (Linux/CygWin)
>> as well as Perl's allocator (when I looked at it 10 years ago), but not
>> necessarily other libc implementations (FreeBSD/OSX, Google, Microsoft) that
>> I didn't try it with, so if anyone could check, that would be interesting.
>>
>> To test that, add millions of atoms to a binbuf and see how much time it
>> takes. A «bad» implementation will roughly quadruple the time each time you
>> double the number individual additions, whereas a «good» one will just
>> double the time.
>>
>
> For the time being, I have something much simpler in mind: Just take the
> current call "int libpd_start_message(void)", which returns the current
> limit, and replace it with "int libpd_start_message(int length)", which
> takes a parameter indicating the length of the message and returns a nonzero
> error code if the length is too big.
>
> I like this idea because it's almost as simple as the original approach,
> and the API agnostic with respect to the policy for handling long messages.
> The tentative implementation that I have right now still has the hard-coded
> limit of 32 elements, and libpd_start_message simply returns an error code
> when asked for a message with more than 32 elements.  The next revision will
> dynamically resize the array if the requested length exceeds the current
> size, and it will only return an error code if the allocation of a larger
> array fails.  Either way, there's no need to reallocate because the array
> contains nothing of interest when libpd_start_message is called, and so we
> can simply throw away the old array and allocate a new one.
>
> The only disadvantage I see is that this doesn't sit well with the
> streaming-style C++ wrapper that Dan created for ofxPd, but I can think of
> workarounds for that.
> Cheers,
>  Peter
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Tue, Aug 30, 2011 at 3:44 PM, Mathieu Bouchard wrote:

> On Tue, 30 Aug 2011, Peter Brinkmann wrote:
>
>  For the time being, I have something much simpler in mind: Just take the
>> current call "int libpd_start_message(void)", which returns the current
>> limit, and replace it with "int libpd_start_message(int length)", which
>> takes a parameter indicating the length of the message and returns a nonzero
>> error code if the length is too big.
>>
>
> But this means that new libpd-using apps won't compile with old versions of
> libpd AND vice-versa.
>

Well, the vast majority of users won't notice any difference at all because
they're using the Android or iOS branch, which I'm updating as I go along.
The only people who are affected by this are those who are using the C
library directly, and I hope that they'll either be willing to update their
code (which should be no more than a two-line change in most cases) or just
stick to the current version, which will remain available via git.

In any case, I think everybody understands that this is still a young
library that needs to adapt as we gain a better understanding of how people
are using it, and the cost of making a small incompatible change is a lot
lower than choosing a suboptimal solution for compatibility with an earlier
version.  This period of youthful innocence is coming to an end, though; the
API has been quite stable for quite a while now, and I believe that it'll
soon be time to declare it finished.  I want to take a critical look at
every piece before we officially lock the API, and I won't be afraid to cut
things that may turn out to be a burden in the long run.  (That's why I
floated the idea of getting rid of the simple message assembly mechanism,
but it looks like that's here to stay.)
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Tue, Aug 30, 2011 at 12:51 PM, Mathieu Bouchard wrote:

> On Tue, 30 Aug 2011, IOhannes m zmoelnig wrote:
>
>  why not simply resize the internal array as needed, starting with 32
>> elements and doubling whenever the limit is reached?
>>
>
> binbuf could be used for that, if the libc's realloc does in effect the
> same thing. i think that this is the case with modern glibc (Linux/CygWin)
> as well as Perl's allocator (when I looked at it 10 years ago), but not
> necessarily other libc implementations (FreeBSD/OSX, Google, Microsoft) that
> I didn't try it with, so if anyone could check, that would be interesting.
>
> To test that, add millions of atoms to a binbuf and see how much time it
> takes. A «bad» implementation will roughly quadruple the time each time you
> double the number individual additions, whereas a «good» one will just
> double the time.
>

For the time being, I have something much simpler in mind: Just take the
current call "int libpd_start_message(void)", which returns the current
limit, and replace it with "int libpd_start_message(int length)", which
takes a parameter indicating the length of the message and returns a nonzero
error code if the length is too big.

I like this idea because it's almost as simple as the original approach, and
the API agnostic with respect to the policy for handling long messages.  The
tentative implementation that I have right now still has the hard-coded
limit of 32 elements, and libpd_start_message simply returns an error code
when asked for a message with more than 32 elements.  The next revision will
dynamically resize the array if the requested length exceeds the current
size, and it will only return an error code if the allocation of a larger
array fails.  Either way, there's no need to reallocate because the array
contains nothing of interest when libpd_start_message is called, and so we
can simply throw away the old array and allocate a new one.

The only disadvantage I see is that this doesn't sit well with the
streaming-style C++ wrapper that Dan created for ofxPd, but I can think of
workarounds for that.
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Mon, Aug 29, 2011 at 1:15 AM, Mathieu Bouchard wrote:

> [...]

and also, I just read your libpd_read_array and libpd_write_array functions.
> They don't work in 64-bit mode, in which sizeof(t_word) != sizeof(t_float).


Okay, should be fixed now.  I just pushed the latest revision to Gitorious.
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

>
>  Here's the problem that it is supposed to solve:  You want to translate a
>> heterogeneous list of objects in Java into an array of type t_atom in C.
>> That's all.
>>
>
> Btw, did you look at Pascal Gauthier's library ?
>

Yes, but I think it solves a different problem.  In particular, I don't want
to mirror t_atom on the Java side.



> and also, I just read your libpd_read_array and libpd_write_array
> functions. They don't work in 64-bit mode, in which sizeof(t_word) !=
> sizeof(t_float).


Yikes, good point.  I'll look into it.
   Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd on Android

[Peter Brinkmann]

On Mon, Aug 29, 2011 at 2:09 PM, athos bacchiocchi <
athos.bacchioc...@gmail.com> wrote:

> 2011/8/29 Pierre Massat 
>
>> I plan on buying my very first smartphone in the next few days. I want a
>> phone running Android since it appears to be the best platform to run Pd. I
>> m just not quite sure about the way Pd can be used with a smartphone
>>
>
> There's Rjdj, which basically runs pd patches without gui (calling them
> "scenes") giving you the possibility to use the smartphone's touchscreen and
> accelerometer as controllers for the patches. So, you still need your pc to
> edit patches, but you can "use" them on the phone. Rjdj is for iphone, but
> you can download an rjdj scene player for android devices here:
>
> http://puredata.info/community/projects/software/sceneplayer
>
> or here:
>
> http://autobuild.puredata.info/pdlab/libpd/
>
> At the second link you will also find an archive with some rjdj "scenes"
> and Pd Test, it should be something similar to scene player but honestly I
> couldn't understand how to use it, i can just test sound (maybe it's
> intended just for that?). Here are some resources on how to build pd-patches
> for rjdj/scene-player.
>

The PdTest app is really just there to check whether Pd will work on your
Android phone, and to let you play with a few parameters like sample rate
and number of channels.

For the time being, we aren't posting binaries on a regular basis.  Instead
of following the links above, you probably want to get the source and build
the Android apps yourself in order to make sure that you have the latest
version.  The code is available here: https://gitorious.org/pdlib



>
> I just started to deal with this stuff, and i have still many doubts and
> difficulties. For example, i still couldn't understand how to download
> scenes from the rjdj website on my android phone, it seems you just can do
> this with an iphone. I hope anyone reading this thread has some useful hints
> :)
>

Scene download from the RjDj website isn't implemented yet.  I'm hoping to
change that soon, at least for those scenes that are available free of
charge.  For the time being, the easiest way to install scenes is to just
copy the .rj folder to your sd-card, or you can fire up the rjzserver and on
your computer and then download scenes from there.  (Make sure to build a
recent version of the ScenePlayer; communication with rjzserver is a fairly
recent addition.)
Good luck,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Mon, Aug 29, 2011 at 1:23 AM, Dan Wilcox  wrote:

> No, I'm talking about sending a list or typed message with libpd as in:
>
> [list 1 2 3 4 ... 32 <
> |
> [s toC++]
>
> The print messaging isn't limited as far as I know.
>

That's right.  The only part that imposes a limit on the message size is the
simple message assembly mechanism for sending lists to Pd.  Lists that are
created elsewhere have no such limitation.


I think it's reasonable to limit the message size, but 32 may be too small
> for some. It would make sense for libpd to have a call that would allow
> users to set the max message size, akin to how you can set the max packet
> size on sockets etc
>

Hmm.  I'm reluctant to add a call for changing the array size because this
entire message assembly API is really just there for the purpose of
simplifying the creation of language bindings.  Any additional complexity
would make it even harder to justify.  So far I've felt that it was
justified because it seemed good enough and I believe its simplicity has
helped the adoption of libpd.  If it turns out to be too limiting (and this
thread suggests that that may be the case), then I'll have to bite the
bullet, deprecate this approach, and write the manual type conversions for
Java and other languages that I'd been trying to avoid.  The good news is
that the latest version of libpd already comes with a new pair of message
passing functions that are not limited in this way.

The current limit was chosen in the following highly scientific fashion:  I
tried to think of the longest list I might want to send as a message, and
the biggest thing I could realistically think of was an OpenGL
transformation, i.e. 4x4 = 16 numbers.  Then I doubled that count and hoped
that that would be enough for everybody.

Maybe we can have a poll and come up with a better estimate.  Here are a few
questions:

1. What sort of use case for long list messages to you have in mind?
2. Exactly how long would you need the list to be?
3. Is this really a use case for list messages or would it make more sense
to write to an array instead?

If we converge to a reasonable number, that'll be the new limit.  Otherwise,
the entire approach may have to go.



> Also, I imagine you don't have this limitation using the new *t_atom
> sending func. Is this true Peter?
>

That's right, there's no intrinsic limitation in the functions.  With the
new approach, you're responsible for creating the t_atom arrays that you're
sending; if you can create it, then the new functions can send it.
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Sun, Aug 28, 2011 at 5:04 PM, Mathieu Bouchard wrote:

> On Sun, 28 Aug 2011, Peter Brinkmann wrote:
>
>  One major simplification is the use of built-in data types vs custom
>> structs and unions.
>>
>
> You mean you simplify by making things more low-level ?
>
> const char * is rarely ever called high-level...


Well, I'm taking a complicated implementation detail (t_symbol) and I'm
providing an API that lets application developers to refer to this detail by
name, without having to think about the data structure behind it.  I
consider that an abstraction, even if the name is given as const char *.



>
>  Incidentally, I've also gotten flak for not baking any multi-instance
>> support into the initial version of libpd (I did consider it, but it seemed
>> pointless because with the current version of Pd it would still have just
>> one single instance).
>>
>
> The point would be to make all the backward-compat and forward-compat you
> need for supporting a future version of pd that will include features that
> you're already thinking about.
>

Nah, that would have been a clear case of overdesign, preparing for some
future development that may never happen.  We'll figure out how to support
multiple instances when multiple instances become a possibility.



> But you don't have to add an argument everywhere. I bet that you'll add a
> libpd_set_current_pd_instance(**t_pd_interpreter *) function that will set
> a global variable used by the rest of the pd api. That would be consistent
> with the stateful message-passing in many small steps using a hidden global
> array. Later you can make all of that thread-safe by making all of those
> functions call pthread_self() to figure out which thread they're in, and
> replace the globals by threadwise-locals.


I thought I had already explained this when we had our little chat over at
pd-everywhere, but I'll try again.   Calling the message assembly API of
libpd stateful is technically true but completely misleading because the
hidden state is only meant to be used in a very specific and limited way.
Here's the problem that it is supposed to solve:  You want to translate a
heterogeneous list of objects in Java into an array of type t_atom in C.
That's all.

Doing the entire conversion in JNI would be a huge pain, and dynamically
allocating t_atom arrays in JNI would be a pain, too.  So, I chose to
allocate one array up front and then provide a set of functions that will
populate the array with values, in a way that's easy to wrap for Java.  The
fact that it's a global array does not cause any problems because the entire
calling sequence needs to be protected by a lock, and so there is only one
method that will ever access the array at one time.  The lock would be
required in any case, because any access to the symbol table needs to be
locked.

The upshot is, the array you mention really acts as a local variable for a
couple of methods in languages like Java or Python or Objective-C.  The fact
that it's currently a hidden global variable is an implementation detail
that does not add problematic global state to libpd.  (I can't even think of
a way to creatively misuse this mechanism to introduce global statue through
the back door.)  Believe me, I've agonized over this, but it's been working
very nicely for more than a year now, and I still can't think of a simpler
way to assemble compound messages in Java.



>  It's more of a general consideration, and I don't have any road map in
>> mind.  Right now I'm just hoping to have a conversation about this.
>>
>
> Well, does that involve multiple interpreters, with one interpreter per
> core, but still in the same process, with a way to pass messages quickly
> from one interpreter to the other?
>

That's not at all what I have in mind.  What I'm really thinking about is
one interpreter that does a topological sort on the signal processing chain
and then parallelizes the computation on the fly, but that's a topic for
another day.  I'm outta here.
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Sun, Aug 28, 2011 at 1:26 PM, Mathieu Bouchard wrote:

> On Sun, 28 Aug 2011, Peter Brinkmann wrote:
>
>  Can you bypass many of the functions in libpd and use m_pd.h directly?
>> Sure, but then again maybe m_pd.h is pointless because you can just hack
>> your binaries with a hex editor.  That doesn't mean that that's a good level
>> of abstraction to work at.  libpd aims to provide a high-level API at a
>> consistent level of abstraction, and I believe that that's the correct level
>> of abstraction for the kind of work that libpd is intended for.
>>
>
> Well, for the libpd message-passing, I felt like it added an API at the
> same level of abstraction as , except a tiny bit slower than
> SETFLOAT and SETSYMBOL macros, and which needed a bit more thread-safety
> than , as even the construction of the message has to be protected.
> Those are really small details, and to me, the biggie is that this API is
> not any easier than 's message passing to a C programmer.


Matter of taste, I suppose.  When working with libpd, I want to think in
terms of calls to libpd.  Reaching into m_pd.h is a context switch that I'd
rather avoid, and with the latest revision of libpd I can avoid it
altogether.  And I do think that saying "libpd_get_symbol(a)" is simpler
than saying "a.a_w.w_symbol->s_name" (although the former is just a macro
that maps to the latter).

Then again, my instincts run libertarian.  I have no desire to tell you how
to do your work.  When you include z_libpd.h, you get m_pd.h with it.  If
you want to work too hard, I won't stand in your way;)



>
>  The immediate motivation was to create an API that would be easy to wrap
>> for languages like Java and Python, but I also have deeper reasons for
>> wanting to work at this level of abstraction.
>>
>
> I don't see any practical difference in easiness of wrapping for other
> languages. I don't know how you see that.


One major simplification is the use of built-in data types vs custom structs
and unions.  Many of the functions that you find pointless basically do two
things; they convert const char* to t_symbol and then delegate to functions
in m_pd.h.  With this transition to built-in data types, you can simply run
SWIG on the header file and automatically create bindings for a significant
part of libpd for lots of target languages; only the callbacks will require
some additional work.  Without this conversion, you would have to descend
into the netherworld of custom typemaps and such.


 I'm hoping that we'll see a major redesign of Pd in the not too distant
> future. One goal we talked about at PdCon is to allow multiple instances of
> Pd.
>

I don't see any planning about this in the way that the libpd api works, and
> I don't see how the libpd api currently helps for that.


It doesn't.  The point is that it would be easy to extend because you'd just
need to add an instance pointer to the parameter list of a smallish
collection of functions.

Incidentally, I've also gotten flak for not baking any multi-instance
support into the initial version of libpd (I did consider it, but it seemed
pointless because with the current version of Pd it would still have just
one single instance).  I figure that as long as I'm drawing fire from both
low-level C hackers and high-level OOP types, I must be doing something
right;)



>  Another change I'm hoping to see is a rewrite that takes advantage of
>> multiple cores on current machines.
>>
>
> What's a «rewrite», and how much actual change do you wish for ? Do you
> have a plan for actual changes to the API ?


It's more of a general consideration, and I don't have any road map in
mind.  Right now I'm just hoping to have a conversation about this.



>
>  I also believe that such changes will be necessary to remain competitive.
>>
>
> If anyone really needs a big speed hike, then how about integrating SSE
> support in vanilla and/or libpd ? The prototype was made in 2005 or so, and
> then abandoned. That's a lot easier to do than to support double/triple/quad
> CPUs.


I'd be more than happy to see that, ideally in vanilla because I want libpd
to remain nothing more than a thin wrapper on top of Pd.



>
>  The libpd API is meant to be (mostly) above such implementation details,
>> while the low-level API will almost certainly change when Pd is updated.  Pd
>> itself will be much more nimble and maintainable if developers think about
>> it at a higher level of abstraction.
>>
>
> What constitutes a higher level of abstraction ?
>

In this case, I mostly mean hiding implementation details.  For example, as
an application programmer I don't want to know what exactly is going on
inside an instance of t_atom, I just want to get string or float values in
and out.
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] sending image from of / libpd

[Peter Brinkmann]

On Sat, Aug 27, 2011 at 11:16 PM, Mathieu Bouchard wrote:

> On Sun, 21 Aug 2011, Hans-Christoph Steiner wrote:
>
>  I think with the libpd API, you can write to Pd arrays.  That's probably
>> you're best bet.
>>
>
> You must be meaning the pd API (m_pd.h).
>
> There's nothing libpd-specific (z_libpd.h) about arrays.
>

That's not true.  Recent versions of libpd come with functions for reading
and writing arrays, memcpy-style.


It's a good thing, because IMHO, many of the functions whose name start with
> the letters «libpd» are pointless, as they can already be done using
> typedmess() and such.
>

Okay, I'll bite.

Pointlessness is in the eye of the beholder.  You may find many of the libpd
wrappers pointless because you're working in C and you're already familiar
with the functions in m_pd.h, but that's not the use case that I had in mind
when writing libpd.

Can you bypass many of the functions in libpd and use m_pd.h directly?
Sure, but then again maybe m_pd.h is pointless because you can just hack
your binaries with a hex editor.  That doesn't mean that that's a good level
of abstraction to work at.  libpd aims to provide a high-level API at a
consistent level of abstraction, and I believe that that's the correct level
of abstraction for the kind of work that libpd is intended for.

The immediate motivation was to create an API that would be easy to wrap for
languages like Java and Python, but I also have deeper reasons for wanting
to work at this level of abstraction.  I'm hoping that we'll see a major
redesign of Pd in the not too distant future.  One goal we talked about at
PdCon is to allow multiple instances of Pd.  Another change I'm hoping to
see is a rewrite that takes advantage of multiple cores on current
machines.  I also believe that such changes will be necessary to remain
competitive.

The libpd API is meant to be (mostly) above such implementation details,
while the low-level API will almost certainly change when Pd is updated.  Pd
itself will be much more nimble and maintainable if developers think about
it at a higher level of abstraction.

In case you're interested, I recently added a few more functions to libpd,
and I wrote up my reasoning behind them in a blog post:
http://nettoyeur.noisepages.com/2011/08/pure-data-convention-libpd-and-a-minor-epiphany/
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PPA for libpd?

[Peter Brinkmann]

I suggest you stick to the central repository of libpd because you can
expect it to be actively maintained and documented.  If other repositories
contain material that you'd like to see in the main branch, you can create a
merge request at Gitorious.
Cheers,
 Peter


On Wed, Jun 22, 2011 at 6:38 PM, august  wrote:

>
>
> well, I just made my first PPA.  It's waiting to build on launchpad.
>
> I have the Makefile copy pd.pc to libpd.pc.   libpd.pc is then installed
> instead of pd.pc
>
> Not sure if I should be using the aalex repo or not.  What are the
> differences?
>
> I don't think the API needs to be fixed for this personal package.
> ...however, maybe for official submission to debian or ubuntu.
>
>
> best -august.
>
> > I agree that we should provide a libpd.pc.  Let's aim to fold this into
> the
> > main branch of the libpd repository.  If the PPA ends up using code from
> > aalex, let's merge that into the main branch as well.
> >
> > A related question is whether this is the time to declare the libpd API
> > finished, but that's a discussion that we should probably take to
> > pd-everywhere.
> > Cheers,
> >  Peter
> >
> >
> > On Wed, Jun 22, 2011 at 3:04 AM, IOhannes m zmoelnig  >wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > On 2011-06-22 05:47, august wrote:
> > > >
> > > >
> > > >
> > > > Is there a version number for libpd?
> > > >
> > > > I see you guys have added a pd.pc in
> > > > http://gitorious.org/~aalex/pdlib/aalexs-libpd
> > > >
> > > just to chime in: please note that "pd" also provides a "pd.pc".
> > > i would highly suggest to provide a libpd.pc for libpd.
> > >
> > > fgmasdr
> > > IOhannes
> > > -BEGIN PGP SIGNATURE-
> > > Version: GnuPG v1.4.11 (GNU/Linux)
> > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > >
> > > iEYEARECAAYFAk4BlAoACgkQkX2Xpv6ydvRg+ACeIu70dOUt/Ovz377qW8h4A5jg
> > > wDQAnjVCznEBzDXU6LmdPSm6IrDQisRQ
> > > =A+mM
> > > -END PGP SIGNATURE-
> > >
> > >
> > > ___
> > > 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
>
>
> --
>---
>http://aug.ment.org
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEVAwUBTgJu9sVXRY8APmlSAQJdYAf+IQVgfwJ7sL9YZ5SLHzq6jeTlh9wVp7bq
> /4XqmZhiW9b32UOz+everEJ+7IMZxkf0t/JICpfkj/D+r478RicdUyY3D8/B3nLZ
> qYHGxJ0JMZgYll63kMW1y8aqQsOTq6oW4dJGocs0p9v6fwnflA9tngdKtj33JpjC
> YBF2fDtgwpqvw1+sHJsevbc7r1zSfOKMxc5T9hvK1lVemmklGw2CkJ61wU4XJSL/
> gZXZp/XN/sbc7AbPNG/zf6eSnIC9/qxYg2Da6RH/37JXIM9qip0RNnI+wXdm/r9y
> cvZzwJsgQsGnGkMD6wGuwnA+g74sKCZ/ItGc5FY2MpWe+BIqomj7QQ==
> =Koa1
> -END PGP SIGNATURE-
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PPA for libpd?

[Peter Brinkmann]

I agree that we should provide a libpd.pc.  Let's aim to fold this into the
main branch of the libpd repository.  If the PPA ends up using code from
aalex, let's merge that into the main branch as well.

A related question is whether this is the time to declare the libpd API
finished, but that's a discussion that we should probably take to
pd-everywhere.
Cheers,
 Peter


On Wed, Jun 22, 2011 at 3:04 AM, IOhannes m zmoelnig wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2011-06-22 05:47, august wrote:
> >
> >
> >
> > Is there a version number for libpd?
> >
> > I see you guys have added a pd.pc in
> > http://gitorious.org/~aalex/pdlib/aalexs-libpd
> >
> just to chime in: please note that "pd" also provides a "pd.pc".
> i would highly suggest to provide a libpd.pc for libpd.
>
> fgmasdr
> IOhannes
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4BlAoACgkQkX2Xpv6ydvRg+ACeIu70dOUt/Ovz377qW8h4A5jg
> wDQAnjVCznEBzDXU6LmdPSm6IrDQisRQ
> =A+mM
> -END PGP SIGNATURE-
>
>
> ___
> 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] RJDJ,sceneplayer & Xoom

[Peter Brinkmann]

Hi Joe,

* The app faithfully implements all features of the iPhone app that were
>> publicly documented last summer, including rj_image, rj_text, sensor input,
>> etc.  There have been a few additions since (scaling and rotating text, I
>> think); those will be easy enough to add when I see the new specs, and I'm
>> not aware of any scenes that require them.  In short, a properly written
>> RjDj scene should look and behave the same for both versions.
>>
>> How do you want the spec Peter? As a Pd patch showing how to use it? I'm
> going to update the help patch for [rj_image] in the RjLib, would that be
> useful?
>

Ideally, I'd like to have a list of all externals and their messages,
including an explanation of the meaning of parameters (e.g., units, origin
and orientation for coordinates and angles, etc.), as well as test
scenes/help patches and maybe videos of how it looks and behaves on an iOS
device.  Realistically, updated help patches would probably be enough to get
me started.


This is really cool Peter. Thanks for you all your work! I don't know about
> Martin, but I don't think many of us in the company are that update with the
> Android development - being that we all have iPhones :)


You're welcome!
Cheers,
 Peter



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

Re: [PD] RJDJ,sceneplayer & Xoom

[Peter Brinkmann]

Hi,
A few clarifications regarding the ScenePlayer app for Android:

* The app faithfully implements all features of the iPhone app that were
publicly documented last summer, including rj_image, rj_text, sensor input,
etc.  There have been a few additions since (scaling and rotating text, I
think); those will be easy enough to add when I see the new specs, and I'm
not aware of any scenes that require them.  In short, a properly written
RjDj scene should look and behave the same for both versions.

* The Android version implements rj_image and friends as abstractions, not
externals.  The immediate practical reason is that the architecture of
Android apps pretty much requires this, but it's also a simpler design that
was possible because of the message-passing features of libpd.  Generally
speaking, I believe that the only externals that you would really want to
use with libpd are those that enhance the signal processing capabilities of
Pd (e.g., fiddle~).  Everything else is more easily implemented outside of
Pd and controlled with messages.

* I don't think it would be a good idea to generalize ScenePlayer to accept
image sizes other than 320x320 because that would almost certainly break
compatibility with the original.  A more realistic approach would be to
tweak the UI so that it'll scale to fill up the screen (while preserving the
aspect ratio) or at least center itself on Honeycomb devices.  I won't have
time to work on this, but if somebody wants to implement this, I'll be happy
to consider a patch.

Cheers,
 Peter




On Wed, Jun 8, 2011 at 9:53 AM, Chris McCormick  wrote:

> Hi Joe,
>
> On Wed, Jun 08, 2011 at 01:59:44PM +0100, Joe White wrote:
> > Couldn't we just update the [rj_image] external in the ScenePlayer on
> Android
> > to accept any sized image?
>
> Sure, but then scenes you make and run with ScenePlayer would be
> incompatible with RjDj on iOS. There are other things to be taken into
> account too, like what happens if your user has a tablet with a different
> aspect ratio? How should images be stretched etc.? A fixed 320x320 bitmap is
> not a great starting point to make things more flexible and still look good.
> Basically you have to break the existing RjDj format if you want those
> features.
>
> With PdDroidParty I am going to provide a facility to bundle SVGs
> ("Scalable Vector Graphic") for your patch background and for each GUI type
> in order to theme them. I was also thinking about 9-patch graphics[1].
> Hopefully this means that patches with fancy graphics will look reasonable
> on all devices. I am some way off from doing that though, and I may run out
> of steam before I get to it. :)
>
> Cheers,
>
> Chris.
>
> [1] http://developer.android.com/guide/developing/tools/draw9patch.html
>
> ---
> http://mccormick.cx
>
> ___
> 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] Graph a circle arc in an array?

[Peter Brinkmann]

On Sat, Apr 9, 2011 at 7:32 PM, Mathieu Bouchard  wrote:

> On Sat, 9 Apr 2011, Peter Brinkmann wrote:
>
>  By the way, there's a way to draw a circle using nothing but addition:
>> http://en.wikipedia.org/wiki/Midpoint_circle_algorithm
>> Implementing this in Pd is completely impractical, but it's fun to think
>> about.
>>
>
> It's not strictly the same thing, because by using sin and cos, you are
> ensuring equal distance between points at infinite resolution, and you are
> ensuring equal angles everywhere too.
>
> With the midpoint circle algorithm, instead, you are ensuring that all
> points are one pixel apart, when using a limited resolution. The pixels are
> considered one pixel apart when sharing an edge or corner. This is related
> to http://en.wikipedia.org/wiki/Maximum_norm
>
> So, it depends on whether you're trying to draw something
> continuous-looking on a pixel display.


Sure, but in this case the goal was to draw a section of a circle in an
array, and the midpoint algorithm would be a good choice if implementing it
in Pd weren't so complex.  Anyway, it doesn't really matter, I just like
Bresenham-style algorithms.
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Graph a circle arc in an array?

[Peter Brinkmann]

By the way, there's a way to draw a circle using nothing but addition:
http://en.wikipedia.org/wiki/Midpoint_circle_algorithm

Implementing this in Pd is completely impractical, but it's fun to think
about.
Cheers,
 Peter


On Sat, Apr 9, 2011 at 2:12 AM, Mathieu Bouchard  wrote:

> On Fri, 8 Apr 2011, Tyler Leavitt wrote:
>
>  I am trying to graph a section of a circle into an array. I have been
>> trying to wrap my head around [sin] and [cos] but none of my configurations
>> get results. If you had a circle with radius 100 with a center at (0, 0) I'm
>> trying to get the upper right quadrant (positive x and positive y). The
>> start point being (100,0) and the end point being (0,100).
>>
>> Any ideas on moving forward?
>>
>
> use angles between 0 and pi/2 = 1.5708
>
> putting those into [cos] and [sin] will give you values for a circle of
> radius 1 at (0,0). For different radiuses you apply [*] after that.
>
> quadrants and clockwiseness depend on which axis uses [cos], which axis
> uses [sin], and which direction of each axis is positive. There are several
> standards for those things.
>
>  ___
> | Mathieu Bouchard  tél: +1.514.383.3801  Villeray, Montréal, QC
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


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

Re: [PD] [PD-announce] workshop: Pd as your embeddable audio engine

[Peter Brinkmann]

On Fri, Apr 8, 2011 at 6:59 AM, patrick  wrote:

>
>  Also, is pdlib just with pd-vanilla, or is it possible to use externals
>> with it?
>>
>
> yes, i use Gem with libpd.


Two comments:

(a)  Awesome!  Would you mind telling us more about your project?

(b) Every once in a while I find myself tempted to port Gem to Android, but
then I wonder whether this would actually make sense.  Essentially, the way
I see it, Gem maps a subset of OpenGL into Pd and controls graphics with Pd
messages.  With libpd, you can use OpenGL directly in your client code and
still exchange messages with Pd, and chances are that it'll be easier to do
the math for OpenGL outside of Pd.  Any thoughts?

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

Re: [PD] [PD-announce] workshop: Pd as your embeddable audio engine

[Peter Brinkmann]

On Fri, Apr 8, 2011 at 6:51 AM, João Pais  wrote:

> NY is a couple thousand Km away from Berlin, so I'm for that as well.
>
> Also, is pdlib just with pd-vanilla, or is it possible to use externals
> with it?
>

The short answer is that yes, externals work with libpd.  A slightly longer
answer is that your operating system determines how externals work.  If
dlopen is available (e.g., on Android), then you can load externals as
needed, the way Pd does it.  If dlopen is not available (e.g., on iOS), then
you need to decide in advance which externals you want to use and compile
them into your code.
  Peter
___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Am I a phone?

[Peter Brinkmann]

On Fri, Mar 25, 2011 at 1:31 PM, ALAN BROOKER wrote:

> Wow that's a good result! I haven't got an iAnything at the moment but
> would love to hear the audio for this...
>
> This may have been asked before but is there a possibility to run Pd on
> Andriod?
>

Yes, there is: http://gitorious.org/pdlib
Cheers,
 Peter
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD'ers in NYC

[Peter Brinkmann]

Hello everybody,
Just a quick reminder that we'll have a patching circle at the VisorLab at
City College tomorrow (Saturday) at 1pm.  The address is 160 Convent Avenue
(take the 1-train to 137th St, or B/C to 135th), and the room is NAC 6/275.
NAC is the huge building at the top of the hill.  I'll tell security to
expect you, but you should probably bring some form of ID just in case.  If
they give you a hard time, give me a call at 917-658-1525.
 Peter

On Thu, Oct 8, 2009 at 10:33 PM, Hans-Christoph Steiner wrote:

>
> Works for me.
>
> .hc
>
> On Oct 8, 2009, at 9:49 PM, Peter Brinkmann wrote:
>
>
> Okay, let's meet at City College at 1pm on Saturday, October 17.
>  Peter
>
>
> On Thu, Oct 8, 2009 at 12:36 AM, Hans-Christoph Steiner wrote:
>
>>
>> Hehe, no 7pm.  Sorry I seemed to have opened up a can of worms with the
>> date change... sorry, it because of my birthday party, so hopefully a worthy
>> cause.
>>
>> I can do 17th or 18th, but others were expressing interest in
>> weeknights... utlimately, Peter, I think you should just choose a time, and
>> those who can make it will show up.  Otherwise we'll be scheduling forever
>> ;)  Then someone else can choose a time that suits their schedule and venue.
>>
>> .hc
>>
>> On Oct 7, 2009, at 12:40 AM, Peter Brinkmann wrote:
>>
>>
>> Do you really mean 7am-10am?  That would be hardcore.  But seriously,
>> weeknights would not work so well because we may have conflicts with regular
>> teaching at the College.  How about the weekend after, October 17 or 18?
>> Best,
>>Peter
>>
>>
>> On Mon, Oct 5, 2009 at 1:37 PM, Hans-Christoph Steiner wrote:
>>
>>>
>>> The Debian-NYC meetings use these doodle time polls quite well, let's try
>>> here.  Basically, just type in a unique ID and the times you can make it,
>>> maybe make it, cannot make it (no login necessary):
>>>
>>> http://doodle.com/96mwth5zekq2xx5y
>>>
>>> .hc
>>>
>>> On Oct 5, 2009, at 1:28 AM, Peter Brinkmann wrote:
>>>
>>>
>>> Okay, now I'm thoroughly confused.  I have no idea who will be attending
>>> and what their constraints are.  If you want to attend, I suggest you send
>>> me a quick email and let me know what dates and times would work for you,
>>> and then I'll see whether I can find a good time for everybody.
>>>  Peter
>>>
>>>
>>> On Fri, Oct 2, 2009 at 9:27 AM, wkc  wrote:
>>>
>>>> Hi,
>>>>
>>>> Although I've just been a lurker I'd also like to add I can't come on
>>>> the 10th or 11th but would definitely show up if it was on any of the other
>>>> dates that Hans-Christoph mentioned.
>>>>
>>>> Will
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>   ¡El pueblo unido jamás será vencido!
>>>
>>>
>>>
>>
>>
>>
>>
>> 
>>
>> The arc of history bends towards justice. - Dr. Martin Luther King,
>> Jr.
>>
>>
>>
>
>
>
>
> 
>
> Mistrust authority - promote decentralization.  - the hacker ethic
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD'ers in NYC

[Peter Brinkmann]

Okay, let's meet at City College at 1pm on Saturday, October 17.
 Peter


On Thu, Oct 8, 2009 at 12:36 AM, Hans-Christoph Steiner wrote:

>
> Hehe, no 7pm.  Sorry I seemed to have opened up a can of worms with the
> date change... sorry, it because of my birthday party, so hopefully a worthy
> cause.
>
> I can do 17th or 18th, but others were expressing interest in weeknights...
> utlimately, Peter, I think you should just choose a time, and those who can
> make it will show up.  Otherwise we'll be scheduling forever ;)  Then
> someone else can choose a time that suits their schedule and venue.
>
> .hc
>
> On Oct 7, 2009, at 12:40 AM, Peter Brinkmann wrote:
>
>
> Do you really mean 7am-10am?  That would be hardcore.  But seriously,
> weeknights would not work so well because we may have conflicts with regular
> teaching at the College.  How about the weekend after, October 17 or 18?
> Best,
>Peter
>
>
> On Mon, Oct 5, 2009 at 1:37 PM, Hans-Christoph Steiner wrote:
>
>>
>> The Debian-NYC meetings use these doodle time polls quite well, let's try
>> here.  Basically, just type in a unique ID and the times you can make it,
>> maybe make it, cannot make it (no login necessary):
>>
>> http://doodle.com/96mwth5zekq2xx5y
>>
>> .hc
>>
>> On Oct 5, 2009, at 1:28 AM, Peter Brinkmann wrote:
>>
>>
>> Okay, now I'm thoroughly confused.  I have no idea who will be attending
>> and what their constraints are.  If you want to attend, I suggest you send
>> me a quick email and let me know what dates and times would work for you,
>> and then I'll see whether I can find a good time for everybody.
>>  Peter
>>
>>
>> On Fri, Oct 2, 2009 at 9:27 AM, wkc  wrote:
>>
>>> Hi,
>>>
>>> Although I've just been a lurker I'd also like to add I can't come on the
>>> 10th or 11th but would definitely show up if it was on any of the other
>>> dates that Hans-Christoph mentioned.
>>>
>>> Will
>>>
>>> ___
>>> 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
>>
>>
>>
>>
>>
>> 
>>
>>   ¡El pueblo unido jamás será vencido!
>>
>>
>>
>
>
>
>
> 
>
> The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD'ers in NYC

[Peter Brinkmann]

Do you really mean 7am-10am?  That would be hardcore.  But seriously,
weeknights would not work so well because we may have conflicts with regular
teaching at the College.  How about the weekend after, October 17 or 18?
Best,
   Peter


On Mon, Oct 5, 2009 at 1:37 PM, Hans-Christoph Steiner wrote:

>
> The Debian-NYC meetings use these doodle time polls quite well, let's try
> here.  Basically, just type in a unique ID and the times you can make it,
> maybe make it, cannot make it (no login necessary):
>
> http://doodle.com/96mwth5zekq2xx5y
>
> .hc
>
> On Oct 5, 2009, at 1:28 AM, Peter Brinkmann wrote:
>
>
> Okay, now I'm thoroughly confused.  I have no idea who will be attending
> and what their constraints are.  If you want to attend, I suggest you send
> me a quick email and let me know what dates and times would work for you,
> and then I'll see whether I can find a good time for everybody.
>  Peter
>
>
> On Fri, Oct 2, 2009 at 9:27 AM, wkc  wrote:
>
>> Hi,
>>
>> Although I've just been a lurker I'd also like to add I can't come on the
>> 10th or 11th but would definitely show up if it was on any of the other
>> dates that Hans-Christoph mentioned.
>>
>> Will
>>
>> ___
>> 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
>
>
>
>
>
> 
>
>   ¡El pueblo unido jamás será vencido!
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD'ers in NYC

[Peter Brinkmann]

Okay, now I'm thoroughly confused.  I have no idea who will be attending and
what their constraints are.  If you want to attend, I suggest you send me a
quick email and let me know what dates and times would work for you, and
then I'll see whether I can find a good time for everybody.
 Peter


On Fri, Oct 2, 2009 at 9:27 AM, wkc  wrote:

> Hi,
>
> Although I've just been a lurker I'd also like to add I can't come on the
> 10th or 11th but would definitely show up if it was on any of the other
> dates that Hans-Christoph mentioned.
>
> Will
>
> ___
> 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] PD'ers in NYC

[Peter Brinkmann]

I'd say some time after breakfast on October 10th.  How about 11am?
 Peter


On Thu, Oct 1, 2009 at 5:46 PM, Hans-Christoph Steiner wrote:

>
> Ok, so set a time and date, and we have an event!  Oct 10th?
>
> .hc
>
> On Oct 1, 2009, at 5:45 PM, Peter Brinkmann wrote:
>
>
> In addition to my lab, we can use the graduate lounge as well as a
> classroom across the hall.  I've got a wireless router in my lab that should
> reach the lounge at least.
>  Peter
>
>
> On Sun, Sep 27, 2009 at 5:52 PM, Peter Brinkmann <
> peter.brinkm...@googlemail.com> wrote:
>
>>
>> There are a few rooms around that might work.  I'll find out whether we
>> can use them and get back to you, probably on Tuesday.
>>  Peter
>>
>>
>>
>> On Sun, Sep 27, 2009 at 2:15 PM, Hans-Christoph Steiner wrote:
>>
>>>
>>> That sounds great.  Do you have a place with tables, chairs and internet
>>> for people to sit around and work?
>>>
>>> .hc
>>>
>>> On Sep 23, 2009, at 11:45 AM, Peter Brinkmann wrote:
>>>
>>>
>>> How about my audiovisual lab at City College  (
>>> http://math.sci.ccny.cuny.edu/pages?name=VisorLab)?  I've got room for
>>> up to 24 people or so.
>>>  Peter
>>>
>>>
>>> On Wed, Sep 23, 2009 at 10:15 AM, Hans-Christoph Steiner 
>>> wrote:
>>>
>>>>
>>>> Anyone have a place to have it?  I asked at Eyebeam to see if we can do
>>>> it there again, we'll see.
>>>>
>>>> .hc
>>>>
>>>>
>>>> On Sep 22, 2009, at 4:55 PM,  <
>>>> simoni...@hispeed.ch> wrote:
>>>>
>>>>  Hey,
>>>>>
>>>>> The 10. October sounds just fine to me! where will the meeting be?
>>>>>
>>>>> simon
>>>>>
>>>>> ___
>>>>> Pd-list@iem.at mailing list
>>>>> UNSUBSCRIBE and account-management ->
>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 
>>>>
>>>> All mankind is of one author, and is one volume; when one man dies, one
>>>> chapter is not torn out of the book, but translated into a better language;
>>>> and every chapter must be so translated -John Donne
>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> Pd-list@iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://lists.puredata.info/listinfo/pd-list
>>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>> Using ReBirth is like trying to play an 808 with a long stick.-David
>>> Zicarelli
>>>
>>>
>>>
>>
>
>
>
>
> 
>
> There is no way to peace, peace is the way.   -A.J. Muste
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD'ers in NYC

[Peter Brinkmann]

In addition to my lab, we can use the graduate lounge as well as a classroom
across the hall.  I've got a wireless router in my lab that should reach the
lounge at least.
 Peter


On Sun, Sep 27, 2009 at 5:52 PM, Peter Brinkmann <
peter.brinkm...@googlemail.com> wrote:

>
> There are a few rooms around that might work.  I'll find out whether we can
> use them and get back to you, probably on Tuesday.
>  Peter
>
>
>
> On Sun, Sep 27, 2009 at 2:15 PM, Hans-Christoph Steiner wrote:
>
>>
>> That sounds great.  Do you have a place with tables, chairs and internet
>> for people to sit around and work?
>>
>> .hc
>>
>> On Sep 23, 2009, at 11:45 AM, Peter Brinkmann wrote:
>>
>>
>> How about my audiovisual lab at City College  (
>> http://math.sci.ccny.cuny.edu/pages?name=VisorLab)?  I've got room for up
>> to 24 people or so.
>>  Peter
>>
>>
>> On Wed, Sep 23, 2009 at 10:15 AM, Hans-Christoph Steiner 
>> wrote:
>>
>>>
>>> Anyone have a place to have it?  I asked at Eyebeam to see if we can do
>>> it there again, we'll see.
>>>
>>> .hc
>>>
>>>
>>> On Sep 22, 2009, at 4:55 PM,  <
>>> simoni...@hispeed.ch> wrote:
>>>
>>>  Hey,
>>>>
>>>> The 10. October sounds just fine to me! where will the meeting be?
>>>>
>>>> simon
>>>>
>>>> ___
>>>> Pd-list@iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://lists.puredata.info/listinfo/pd-list
>>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>> All mankind is of one author, and is one volume; when one man dies, one
>>> chapter is not torn out of the book, but translated into a better language;
>>> and every chapter must be so translated -John Donne
>>>
>>>
>>>
>>>
>>> ___
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>>
>>
>>
>> 
>>
>> Using ReBirth is like trying to play an 808 with a long stick.-David
>> Zicarelli
>>
>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD'ers in NYC

[Peter Brinkmann]

There are a few rooms around that might work.  I'll find out whether we can
use them and get back to you, probably on Tuesday.
 Peter


On Sun, Sep 27, 2009 at 2:15 PM, Hans-Christoph Steiner wrote:

>
> That sounds great.  Do you have a place with tables, chairs and internet
> for people to sit around and work?
>
> .hc
>
> On Sep 23, 2009, at 11:45 AM, Peter Brinkmann wrote:
>
>
> How about my audiovisual lab at City College  (
> http://math.sci.ccny.cuny.edu/pages?name=VisorLab)?  I've got room for up
> to 24 people or so.
>  Peter
>
>
> On Wed, Sep 23, 2009 at 10:15 AM, Hans-Christoph Steiner wrote:
>
>>
>> Anyone have a place to have it?  I asked at Eyebeam to see if we can do it
>> there again, we'll see.
>>
>> .hc
>>
>>
>> On Sep 22, 2009, at 4:55 PM,  
>> wrote:
>>
>>  Hey,
>>>
>>> The 10. October sounds just fine to me! where will the meeting be?
>>>
>>> simon
>>>
>>> ___
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>>
>>
>>
>> 
>>
>> All mankind is of one author, and is one volume; when one man dies, one
>> chapter is not torn out of the book, but translated into a better language;
>> and every chapter must be so translated -John Donne
>>
>>
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>
>
>
> 
>
> Using ReBirth is like trying to play an 808 with a long stick.-David
> Zicarelli
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD'ers in NYC

[Peter Brinkmann]

How about my audiovisual lab at City College  (
http://math.sci.ccny.cuny.edu/pages?name=VisorLab)?  I've got room for up to
24 people or so.
 Peter


On Wed, Sep 23, 2009 at 10:15 AM, Hans-Christoph Steiner wrote:

>
> Anyone have a place to have it?  I asked at Eyebeam to see if we can do it
> there again, we'll see.
>
> .hc
>
>
> On Sep 22, 2009, at 4:55 PM,  
> wrote:
>
>  Hey,
>>
>> The 10. October sounds just fine to me! where will the meeting be?
>>
>> simon
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>
>
>
> 
>
> All mankind is of one author, and is one volume; when one man dies, one
> chapter is not torn out of the book, but translated into a better language;
> and every chapter must be so translated -John Donne
>
>
>
>
> ___
> 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] Is anyone using csoundapi~?

[Peter Brinkmann]

Mike,
Sorry about the tardy reply; I've been traveling.

The new version of csoundapi~ is in the CVS repository of Csound.  You can
find a tentative documentation patch at
http://math.sci.ccny.cuny.edu/docs?name=csapidoc.tar; please note that this
one hasn't quite made it into the official CVS yet, but it should still be
helpful.  Also, in case you're using Csound under Mac OS X and are leery of
build problems, the latest CVS version includes a patch that fixes the last
compilation issue I encountered.  The current version builds just fine, at
least on my machine (after changing custom.py to reflect that Darwin Ports
puts libs and headers in strange places; ymmv...).
Best,
 Peter


On Wed, Aug 13, 2008 at 7:00 PM, Mike McGonagle <[EMAIL PROTECTED]> wrote:

> Peter,
>
> Which CVS are you talking about? CSound? Pure Data? And yes, if you could
> let me know when the examples are in the CVS, that would be great. While I
> am currently not using MIDI with CSound, I am pretty much leaving that to
> Pd, it might be interesting to work with.
>
> Thanks,
>
> Mike
>
>
> On Wed, Aug 13, 2008 at 5:35 PM, Peter Brinkmann <
> [EMAIL PROTECTED]> wrote:
>
>>
>> Hi Mike,
>> I use csoundapi~ a bit and it works fine for me.  And yes, there is a more
>> recent version; the current version in CVS takes MIDI commands, much like
>> the corresponding object for MAX/MSP.  I've prepared a few sample patches
>> for the new MIDI functionality.  They aren't in CVS yet, but I can post them
>> if you're interested.
>> Best,
>>Peter
>>
>>
>> On Mon, Aug 11, 2008 at 2:44 PM, Mike McGonagle <[EMAIL PROTECTED]> wrote:
>>
>>> Hello,
>>>
>>> I recently started to use the Csoundapi~ external, and was wondering if
>>> anyone has been using it, and if there are any troubles you have
>>> encountered.
>>>
>>> I also was wondering (after reading someone's posts) about the priorities
>>> under which these things run. I would imagine that with it being an external
>>> of PD that it runs in the same address space (maybe?) and that the
>>> priorities given to the code would be the same.
>>>
>>> Is there a better way to us CSound with PD? OSC? Can CSound be run as a
>>> server (alla Supercollider)?
>>>
>>> Also, is there a more recent version of the external? While I haven't
>>> experienced any troubles, I am wondering what version of Pure Data that the
>>> compiled version that comes with Csound 5.08 was compiled against.
>>>
>>>
>>> Mike
>>>
>>>
>>> --
>>> Peace may sound simple—one beautiful word— but it requires everything we
>>> have, every quality, every strength, every dream, every high ideal.
>>> —Yehudi Menuhin (1916–1999), musician
>>>
>>> ___
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>
>
> --
> Peace may sound simple—one beautiful word— but it requires everything we
> have, every quality, every strength, every dream, every high ideal.
> —Yehudi Menuhin (1916–1999), musician
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Is anyone using csoundapi~?

[Peter Brinkmann]

Hi Mike,
I use csoundapi~ a bit and it works fine for me.  And yes, there is a more
recent version; the current version in CVS takes MIDI commands, much like
the corresponding object for MAX/MSP.  I've prepared a few sample patches
for the new MIDI functionality.  They aren't in CVS yet, but I can post them
if you're interested.
Best,
   Peter


On Mon, Aug 11, 2008 at 2:44 PM, Mike McGonagle <[EMAIL PROTECTED]> wrote:

> Hello,
>
> I recently started to use the Csoundapi~ external, and was wondering if
> anyone has been using it, and if there are any troubles you have
> encountered.
>
> I also was wondering (after reading someone's posts) about the priorities
> under which these things run. I would imagine that with it being an external
> of PD that it runs in the same address space (maybe?) and that the
> priorities given to the code would be the same.
>
> Is there a better way to us CSound with PD? OSC? Can CSound be run as a
> server (alla Supercollider)?
>
> Also, is there a more recent version of the external? While I haven't
> experienced any troubles, I am wondering what version of Pure Data that the
> compiled version that comes with Csound 5.08 was compiled against.
>
>
> Mike
>
>
> --
> Peace may sound simple—one beautiful word— but it requires everything we
> have, every quality, every strength, every dream, every high ideal.
> —Yehudi Menuhin (1916–1999), musician
>
> ___
> 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] pyext and canvas_getcurrentdir()

[Peter Brinkmann]

Hi Thomas,
Thanks for your reply!

> Does pyext offer Python bindings for functions like
> > canvas_getcurrentdir() from m_pd.h?
> >
>
> currently it doesn't, but i'll see if i can add it


That would be great.  Not to seem greedy, but there are a few more functions
in there that would be good to have, such as canvas_dspstate().

In addition (and almost more importantly), I would like to have pyext set
the working directory of the Python interpreter to canvas_getcurrentdir()
upon initialization.
Best,
Peter
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pyext and canvas_getcurrentdir()

[Peter Brinkmann]

Hi all,
Does pyext offer Python bindings for functions like canvas_getcurrentdir()
from m_pd.h?

I looked at the source code and noticed that pyext appends the current
directory to the Python search path, so that I get the current directory via
sys.path[-1].  I'm a little worried, though, that this behavior may change
in a future revision of pyext.
Best,
   Peter
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list