[PD] displaying patches on the web

[Jonathan Wilkes]

Hi list,

Anyone have a way to render pd sourcecode into a 

patch using html5?  I was looking at the new design 

for Diaspora:
http://blog.diasporafoundation.org/

If they make it possible to define your own templates in 

the future it would be a cool way of posting pd source 

code and viewing the patch (as well as copy-pasting 

it after seeing it, which pd-l2ork can currently do).
I was thinking you could also just embed pd source code 
in a gif file and make a drag-and-drop gui-plugin that 
reads/writes such gifs, but it seems like that could easily 
be used to spread virii.


-Jonathan


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

Re: [PD] Pd on ARM devices

[Hans-Christoph Steiner]

There are some fedora packages of pd floating around.  It would be great for 
someone to update them and include them in the pure-data SVN or some repo 
somewhere.  Also, if someone makes a fedora package .spec file for the Library 
Template, it'll be really easy to package lots of other libraries for Fedora.

If you get Debian running on the Pi, then just apt-get install puredata.

.hc

On Feb 29, 2012, at 1:15 PM, Scott R. Looney wrote:

> i figure it won't be too long before nearly everyone including planet CCRMA 
> has a build going specifically for the Pi. there' s a very good chance the Pi 
> Foundation can license the design to other makers, so by May or so i'd bet a 
> number of different places will have them in stock. the biggest issue for me 
> is how much DSP performance you get out of something whose speed matches the 
> iPhone 3GS. the awesome thing would be to put their display engine to work 
> doing DSP but i think that's a long way down the line if ever due to the 
> limited API access. i started a thread about this a bit ago and if i 
> remember, the falling down point of ARM was that it didn't handle floating 
> point well. i'd be curious how much these devices could be pushed.
> 
> scott
> 
> 
> On Wed, Feb 29, 2012 at 1:01 PM, Charles Henry  wrote:
> On Wed, Feb 29, 2012 at 12:39 PM, Pierre Massat  wrote:
> >
> >
> > 2012/2/29 Charles Henry 
> >>
> >> On Wed, Feb 29, 2012 at 10:06 AM, Pierre Massat 
> >> wrote:
> >> > Dear List,
> >> >
> >> > I'm planning to buy a Raspberry Pi sometime soon, and I'd like to know
> >> > the
> >> > implications of the ARM11 chip on the use of Pd.
> >> > I know nothing about the differences in architectures, so i'd like to
> >> > know :
> >> > - why an ARM chip would be a problem for compiling, installing and
> >> > running
> >> > Pd,
> >>
> >> It's not a problem--Pd compiles and runs on the arm architecture.
> >> Android devices for example have arm processors.  Debian pure data
> >> packages are available for arm.
> >
> >
> > That's good news! I suppose Debian packages can't be installed in Fedora,
> > can they?
> 
> No--planet CCRMA has some i386 pd packages, but not arm.  If you want
> to run Fedora and Pd, you will need to compile it.If only you knew
> the power of the dark side, and by dark side, I mean Debian.
> 
> If you didn't get your pre-order in time for this batch, you'll have
> to wait a month, I bet.  By the time I got to work this morning, it
> was too late.
> 
> ___
> 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




“We must become the change we want to see. - Mahatma Gandhi

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

Re: [PD] seeking help for compiling libpd.dll (mingw)

[Hans-Christoph Steiner]

You could probably start with the pd/src/makefile.mingw that included in pd 
vanilla and extended.

.hc

On Feb 29, 2012, at 4:43 PM, patrick wrote:

> hi all,
> 
> i want to compile libpd on windows using mingw. i have no experience with 
> windows - mingw. what i would like to have is "libpd.dll" that i can link 
> (-lpd) in C, C++ and even C#.
> 
> dan wilcox helped me, but i am afraid i don't quite understand how to proceed 
> with this information:
> 
> "...
> You will need a pthreads lib on Win, and can try pthreads-win32 although it's 
> getting old. You will also need the following C flags: -DHAVE_UNISTD_H 
> -DUSEAPI_DUMMY -DPD
> 
> Check out the readme on my VS branch on github: 
> https://github.com/danomatika/ofxPd/tree/visual-studio
> ...
> "
> 
> thanks
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list




I hate it when they say, "He gave his life for his country."  Nobody gives 
their life for anything.  We steal the lives of these kids.  -Admiral Gene 
LeRocque


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

Re: [PD] latest Pd-Extended cpu usage (was: new editing features of Pd-extended 0.43, now in beta)

[Hans-Christoph Steiner]

Pd-extended uses a quite a bit more recent version of portaudio, but that seems 
to be making things worse here.  That update helps in other things tho.  This 
stuff is really not my specialty, so I'd appreciate help with it.

One thing i have seen is that using JackOSX makes the idle CPU usage go down to 
about 2%.  I think JackOSX also bypasses all that Apple postprocessing.

.hc

On Feb 29, 2012, at 6:17 AM, Rich E wrote:

> Note that the issue I'm seeing is a difference in cpu usage between 
> Pd-Extended and Pd-vanilla.  In OS X 10.7, when opening up each version of pd 
> and looking at Activity Monitor (before every opening a patch or turning on 
> DSP), I get:
> 
> - Pd-0.43.1-extended-20120228 running at ~ 17% cpu
> - Pd-0.43-1 running at ~ 7% cpu
> 
> I can file this on sourceforge if it would be easier to track there.
> 
> On Wed, Feb 29, 2012 at 8:56 PM, Jamie Bullock  wrote:
> 
> 
> On 28 Feb 2012, at 21:10, katja wrote:
> 
> >
> >
> > On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock  wrote:
> >
> > Yup, I think this is related to the Portaudio driver. I reported it here:
> >
> >
> > http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=55736&atid=478070
> >
> > I don't think it's Portaudio itself that's at fault, but rather the way it 
> > interfaces with Pd.
> >
> >
> > DspFuncLib is in:
> >
> >  
> > /System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
> >
> > If you run command nm on the lib, you'll see a plethora of dsp functions 
> > like MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and 
> > whatnot. Functions in this lib are called when the internal soundcard is 
> > used. When using an external soundcard with Pd, DspFuncLib is not called 
> > and that makes the big difference in CPU load.
> >
> > AppleHDA and mach_kernel are Apple libs as well and together with 
> > DspFuncLib they are responsible for the crazy CPU load in the 
> > 'idle-but-dsp-on' case.
> >
> > PortAudio functions are apparently statically built into Pd and they 
> > consume very little CPU time.
> >
> 
> It seems that you're right, so I've closed the bug (my apologies to 
> PortAudio!).
> 
> I guess the real 'fix' for this is that Pd now has a block size setting in 
> Preferences. With a block size of 1024, using the PortAudio driver I get a 
> CPU use of <2% with DSP on. Checking "use callbacks" also seems to reduce 
> CPU. Here, I got a reduction of ~2% with that checked.
> 
> Also, I'm not sure if this is an improvement in recent versions of OS X, but 
> Pd now runs at only ~5% with DSP on using the PortAudio driver with a 
> blocksize of 64. This is on a MacBook Air i7/1.8.
> 
> best,
> 
> Jamie
> 
> --
> http://www.jamiebullock.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






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] seeking help for compiling libpd.dll (mingw)

[patrick]

hi all,

i want to compile libpd on windows using mingw. i have no experience 
with windows - mingw. what i would like to have is "libpd.dll" that i 
can link (-lpd) in C, C++ and even C#.


dan wilcox helped me, but i am afraid i don't quite understand how to 
proceed with this information:


"...
You will need a pthreads lib on Win, and can try pthreads-win32 although 
it's getting old. You will also need the following C flags: 
-DHAVE_UNISTD_H -DUSEAPI_DUMMY -DPD


Check out the readme on my VS branch on github: 
https://github.com/danomatika/ofxPd/tree/visual-studio

...
"

thanks

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

Re: [PD] roughness & Pitch-Comonality objects (was Re: number to fractions external?)

[Alexandre Torres Porres]

well, there was that HD crash, but I worked a lot on top of what we had,
things have changed, and now I'm changing it even more, you dont have the
latest versions, after my defense, in a month, I might have reasonable
lauchable first version, I hope you can help me revise them, see if you
find something weird, that's all.

thanks


Em 18 de fevereiro de 2012 16:01, Mathieu Bouchard escreveu:

> Le 2012-02-14 à 13:54:00, Alexandre Torres Porres a écrit :
>
>
>  the object code is fine, but I've changed it, just have a look to see if
>> you find something funny.
>>
>
> Can you just make a list of all the components that I worked on, to see
> whether I have all of them. I remember that I didn't have a copy of
> everything, and some files were lost in a HD crash, but I don't remember
> whether everything was recovered in the end, and whether I have the latest
> versions.
>
> You see, it was a long time ago already...
>
>
>  __**__**
> __
> | 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] pvoc~ / classic vocoder

[Alexandre Torres Porres]

Hey, Tom Erbe put out on facebook today a nice classic vocoder liked oI
asked the other http://vimeo.com/37680757

I was about to include something like this on my computer music examples, I
may base myself on this implementation

cheers
Alex


=

Hi, I've seen around this listed in a few pages as a pd object

pvoc~ an additive synthesis phase vocoder
is it out there somewhere for real?

cant find it.

Oh, by the way. is there some Classic old school frequency band vocoder
implemented as a Pd patch somewhere around? I dont mean miller's "timbre
stamp" example, or a few objects I've seen, or the bark spectrum phase
vocoder from timbreID. Got it?

-

By the way, I'm preparing a new update on my tutorials I've been using on
FFT workshops. Will put them out here soon. They started off in portuguese,
but I've been converting them to english.

Oh, and here's something ironic; this is a very cool Phase Vocoder tutorial
as I pointed out http://cycling74.com/2006/11/02/the-phase-vocoder-–-part-i/ .
It shows how to do it in polar and cartesian form, but I never tested their
patches. So I got curious and downloaded max 6 demo to try them. The
cartesian form actually doesn't seem to work well at all! And it is totally
based on Miller's I07 example patch.

Anyway, I did a polar version of the phase vocoder with [cartopol~] /
[poltocar~] objetcs. It does look much simpler and easier to understand.

So, I will put them out soon.

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

Re: [PD] Pd on ARM devices

[Scott R. Looney]

i figure it won't be too long before nearly everyone including planet CCRMA
has a build going specifically for the Pi. there' s a very good chance the
Pi Foundation can license the design to other makers, so by May or so i'd
bet a number of different places will have them in stock. the biggest issue
for me is how much DSP performance you get out of something whose speed
matches the iPhone 3GS. the awesome thing would be to put their display
engine to work doing DSP but i think that's a long way down the line if
ever due to the limited API access. i started a thread about this a bit ago
and if i remember, the falling down point of ARM was that it didn't handle
floating point well. i'd be curious how much these devices could be pushed.

scott


On Wed, Feb 29, 2012 at 1:01 PM, Charles Henry  wrote:

> On Wed, Feb 29, 2012 at 12:39 PM, Pierre Massat 
> wrote:
> >
> >
> > 2012/2/29 Charles Henry 
> >>
> >> On Wed, Feb 29, 2012 at 10:06 AM, Pierre Massat 
> >> wrote:
> >> > Dear List,
> >> >
> >> > I'm planning to buy a Raspberry Pi sometime soon, and I'd like to know
> >> > the
> >> > implications of the ARM11 chip on the use of Pd.
> >> > I know nothing about the differences in architectures, so i'd like to
> >> > know :
> >> > - why an ARM chip would be a problem for compiling, installing and
> >> > running
> >> > Pd,
> >>
> >> It's not a problem--Pd compiles and runs on the arm architecture.
> >> Android devices for example have arm processors.  Debian pure data
> >> packages are available for arm.
> >
> >
> > That's good news! I suppose Debian packages can't be installed in Fedora,
> > can they?
>
> No--planet CCRMA has some i386 pd packages, but not arm.  If you want
> to run Fedora and Pd, you will need to compile it.If only you knew
> the power of the dark side, and by dark side, I mean Debian.
>
> If you didn't get your pre-order in time for this batch, you'll have
> to wait a month, I bet.  By the time I got to work this morning, it
> was too late.
>
> ___
> 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 ARM devices

[Charles Henry]

On Wed, Feb 29, 2012 at 12:39 PM, Pierre Massat  wrote:
>
>
> 2012/2/29 Charles Henry 
>>
>> On Wed, Feb 29, 2012 at 10:06 AM, Pierre Massat 
>> wrote:
>> > Dear List,
>> >
>> > I'm planning to buy a Raspberry Pi sometime soon, and I'd like to know
>> > the
>> > implications of the ARM11 chip on the use of Pd.
>> > I know nothing about the differences in architectures, so i'd like to
>> > know :
>> > - why an ARM chip would be a problem for compiling, installing and
>> > running
>> > Pd,
>>
>> It's not a problem--Pd compiles and runs on the arm architecture.
>> Android devices for example have arm processors.  Debian pure data
>> packages are available for arm.
>
>
> That's good news! I suppose Debian packages can't be installed in Fedora,
> can they?

No--planet CCRMA has some i386 pd packages, but not arm.  If you want
to run Fedora and Pd, you will need to compile it.If only you knew
the power of the dark side, and by dark side, I mean Debian.

If you didn't get your pre-order in time for this batch, you'll have
to wait a month, I bet.  By the time I got to work this morning, it
was too late.

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

Re: [PD] C++ for reusable dsp lib - or better use C?

[Thomas Grill]

Hi Katja,
maybe i'm chiming in too late, but i would definitely use C++ programming for 
whatever i do in the C-world.
It's no problem to make the public API (exported functions) C-style then to 
avoid various hassles.
If your library is just a wrapper it might not be worth to live in both worlds, 
but if it's a substantial amount of code, i would go for C++ with a C interface.
gr~~~

Am 22.02.2012 um 02:12 schrieb katja:

> Hello Mathieu, IOhannes, Hans, Marvin,
> 
> Thanks for all your informed answers.
> 
> I was considering C++ just for programming comfort. I know that
> everything can be done in C but it is so clumsy for making class-like
> things. If Pd would be conceived today, would it be written in C?
> 
> But indeed, C++ ABI complexities make it harder to get a C++ lib
> working always and everywhere. I've come across the MSVC/GNU
> incompatibility, but didn't know about the GNU version conflicts
> mentioned by Mathieu.
> 
> So, the comfort of C++ programming and the time saved during
> development may be outweighed by troubles in deployment? I have to
> think twice... My lib should easily build and run wherever Pd runs.
> 
> I started reading Axel-Tobias Schreiner's 'Object-Oriented Programming
> with ANSI-C', found via Marvin's link. The title made me enthusiastic
> for a moment. I like C. But for OOP? It's a lot of dull
> administration.
> 
> Fortunately I've time to reflect a bit more on the options, this lib
> need not be written today or tomorrow. Thanks again for all the
> advice.
> 
> Katja
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

--
Thomas Grill
http://g.org
+43 699 19715543


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

Re: [PD] Pd on ARM devices

[Pierre Massat]

2012/2/29 Charles Henry 

> On Wed, Feb 29, 2012 at 10:06 AM, Pierre Massat 
> wrote:
> > Dear List,
> >
> > I'm planning to buy a Raspberry Pi sometime soon, and I'd like to know
> the
> > implications of the ARM11 chip on the use of Pd.
> > I know nothing about the differences in architectures, so i'd like to
> know :
> > - why an ARM chip would be a problem for compiling, installing and
> running
> > Pd,
>
> It's not a problem--Pd compiles and runs on the arm architecture.
> Android devices for example have arm processors.  Debian pure data
> packages are available for arm.
>

That's good news! I suppose Debian packages can't be installed in Fedora,
can they?


> compilation-wise... there's some gcc options that you use to specify
> arm architectures.  I'd say "nothing to it", but you'll most likely
> have to play a bit to find the differences.
>
> > - if there exists another option that's up to date (Pda seems a bit old),
> > - if Libpd could be used instead (given that i only want to run Pd
> patches
> > on the Raspberry Pi, I don't need to edit anything on it).
>
> Don't you want to try the graphics processor on the R. Pi?  At the
> very least, it should be good enough for tcl/tk.
>

If Pd can be installed then I'll definitely stick to it.


>
> >
> > Thank you in advance!
> >
> > Cheers!
> >
> > Pierre.
> >
> > ___
> > 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 ARM devices

[Charles Henry]

On Wed, Feb 29, 2012 at 10:06 AM, Pierre Massat  wrote:
> Dear List,
>
> I'm planning to buy a Raspberry Pi sometime soon, and I'd like to know the
> implications of the ARM11 chip on the use of Pd.
> I know nothing about the differences in architectures, so i'd like to know :
> - why an ARM chip would be a problem for compiling, installing and running
> Pd,

It's not a problem--Pd compiles and runs on the arm architecture.
Android devices for example have arm processors.  Debian pure data
packages are available for arm.

compilation-wise... there's some gcc options that you use to specify
arm architectures.  I'd say "nothing to it", but you'll most likely
have to play a bit to find the differences.

> - if there exists another option that's up to date (Pda seems a bit old),
> - if Libpd could be used instead (given that i only want to run Pd patches
> on the Raspberry Pi, I don't need to edit anything on it).

Don't you want to try the graphics processor on the R. Pi?  At the
very least, it should be good enough for tcl/tk.

>
> Thank you in advance!
>
> Cheers!
>
> Pierre.
>
> ___
> 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 ARM devices

[Mathieu Bouchard]

Le 2012-02-29 à 17:06:00, Pierre Massat a écrit :


I'm planning to buy a Raspberry Pi sometime soon, and I'd like to know the 
implications of the ARM11 chip on the use of Pd.
I know nothing about the differences in architectures, so i'd like to know :
- why an ARM chip would be a problem for compiling, installing and running Pd,
- if there exists another option that's up to date (Pda seems a bit old),
- if Libpd could be used instead (given that i only want to run Pd patches on 
the Raspberry Pi, I don't need to edit anything on it).


At work, I use an iPhone ARM7, and an Android ARM7, with basically the 
same libpd build on each.


I'm using it through the m_pd.h interface as much as possible instead of 
libpd's own ; either can be used.


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

[PD] Pd on ARM devices

[Pierre Massat]

Dear List,

I'm planning to buy a Raspberry Pi sometime soon, and I'd like to know the
implications of the ARM11 chip on the use of Pd.
I know nothing about the differences in architectures, so i'd like to know :
- why an ARM chip would be a problem for compiling, installing and running
Pd,
- if there exists another option that's up to date (Pda seems a bit old),
- if Libpd could be used instead (given that i only want to run Pd patches
on the Raspberry Pi, I don't need to edit anything on it).

Thank you in advance!

Cheers!

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

Re: [PD] OSC Sequencer IanniX

[Christoph Kuhr]

Hi chris,

I could do a x64 build for linux if you like to...

I'd welcome developer contributions once I get this version
>sufficiently complete.
>
>It does now support midi clock, midi position pointer and midi time
>code so it's easier to work with other midi based software - so far
>tested with Live and Numerology.  And I've included a placeholder for
>OSC based syncing, waiting to be implemented.
>
>Also, if anyone wants to help with a Linux build I'd be happy to work
>with you.
>
>- Chris
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

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

Re: [PD] Pd-list Digest, Vol 83, Issue 169

[Maggie]

yes, Thomas smeeton.

Thanks.

-
Sent from mBox Mail
Hotmail for iPhone and iPod Touch
http://www.fluentfactory.com/mboxmail



On 2012-02-29 13:38:53 + pd-list-requ...@iem.at wrote:

> 
> Send Pd-list mailing list submissions to
>   pd-list@iem.at
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.puredata.info/listinfo/pd-list
> or, via email, send a message with subject or body 'help' to
>   pd-list-requ...@iem.at
> 
> You can reach the person managing the list at
>   pd-list-ow...@iem.at
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pd-list digest..."
> 
> 
> Today's Topics:
> 
>1. Re: latest Pd-Extended cpu usage (was: new editing features
>   of Pd-extended 0.43, now in beta) (Rich E)
>2. pddroidparty netsend and netreceive (Orm Finnendahl)
>3. Re: pddroidparty netsend and netreceive (berenger recoules)
>4. Re: pddroidparty netsend and netreceive (Ga?l Dubus)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 29 Feb 2012 22:17:42 +1100
>  From: Rich E 
> Subject: Re: [PD] latest Pd-Extended cpu usage (was: new editing
>   features of Pd-extended 0.43, now in beta)
> To: Jamie Bullock 
> Cc: pd-list@iem.at
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Note that the issue I'm seeing is a difference in cpu usage between
> Pd-Extended and Pd-vanilla.  In OS X 10.7, when opening up each version of
> pd and looking at Activity Monitor (before every opening a patch or turning
> on DSP), I get:
> 
> - Pd-0.43.1-extended-20120228 running at ~ 17% cpu
> - Pd-0.43-1 running at ~ 7% cpu
> 
> I can file this on sourceforge if it would be easier to track there.
> 
> On Wed, Feb 29, 2012 at 8:56 PM, Jamie Bullock  wrote:
> 
>> 
>> 
>> On 28 Feb 2012, at 21:10, katja wrote:
>> 
>>> 
>>> 
>>> On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock 
>> wrote:
>>> 
>>> Yup, I think this is related to the Portaudio driver. I reported it here:
>>> 
>>> 
>> http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=55736&atid=478070
>>> 
>>> I don't think it's Portaudio itself that's at fault, but rather the way
>> it interfaces with Pd.
>>> 
>>> 
>>> DspFuncLib is in:
>>> 
>>> 
>>   
>> /System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
>>> 
>>> If you run command nm on the lib, you'll see a plethora of dsp functions
>> like MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and
>> whatnot. Functions in this lib are called when the internal soundcard is
>> used. When using an external soundcard with Pd, DspFuncLib is not called
>> and that makes the big difference in CPU load.
>>> 
>>> AppleHDA and mach_kernel are Apple libs as well and together with
>> DspFuncLib they are responsible for the crazy CPU load in the
>> 'idle-but-dsp-on' case.
>>> 
>>> PortAudio functions are apparently statically built into Pd and they
>> consume very little CPU time.
>>> 
>> 
>> It seems that you're right, so I've closed the bug (my apologies to
>> PortAudio!).
>> 
>> I guess the real 'fix' for this is that Pd now has a block size setting in
>> Preferences. With a block size of 1024, using the PortAudio driver I get a
>> CPU use of <2% with DSP on. Checking "use callbacks" also seems to reduce
>> CPU. Here, I got a reduction of ~2% with that checked.
>> 
>> Also, I'm not sure if this is an improvement in recent versions of OS X,
>> but Pd now runs at only ~5% with DSP on using the PortAudio driver with a
>> blocksize of 64. This is on a MacBook Air i7/1.8.
>> 
>> best,
>> 
>> Jamie
>> 
>> --
>> http://www.jamiebullock.com
>> 
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>> 
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.puredata.info/pipermail/pd-list/attachments/20120229/8d963ffb/attachment-0001.htm>
> 
> --
> 
> Message: 2
> Date: Wed, 29 Feb 2012 12:41:44 +0100
>  From: Orm Finnendahl 
> Subject: [PD] pddroidparty

Re: [PD] pddroidparty netsend and netreceive

[Gaël Dubus]

On 2/29/12 12:58 PM, berenger recoules wrote:

Hi

in my experience, I managed to send data from Droidparty to my 
computer but not the other way around, using the netro object by Chris.


you can check the netro object that uses netsend and netreceives : 
http://code.google.com/p/pd-netro/


actually i also tried it on an iphone with rjdj and I can send data to 
the iphone from my computer but not the other way around.


when I worked with it i'm not sure the version of pd used for libpd at 
this time was 0.43. As Chris mentions in the google code, [netro] 
works with 0.43 and higher, it's maybe the time to give it another try.


cheers

Bérenger




2012/2/29 Orm Finnendahl >


Hi,

 I'm checking out pddroidparty for communication between an android
device and a pd patch on another computer. It doesn't seem to be
possible to send to or receive any events using the netsend and
netreceive objects.

I can ping both devices. Establishing a connection and sending numbers
from the computer to a numberbox in the android patch gives no errors
in the pd window on the computer, but the numbers aren't displayed on
the device. The same happens sending data from the android to the
computer. I can telnet the port on the android when pddroidparty runs
the patch (and get a "connection refused" message if the patch has
been closed) so it seems that there is no firewall blocking the
communication.

Does anybody know about this issue or has anybody successfully
established netconnections between pddroidparty and another computer
and could give some advice?

--
Orm

___
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


Hi,
I am facing kind of the same problem with ScenePlayer on Android.

For some time ago, I wanted to make another phone application 
communicate with ScenePlayer. My idea was to inject the data into 
ScenePlayer via localhost using networking utilities of Pd. For this 
purpose, I recompiled ScenePlayer including externals from the mrpeach 
library, then I tried several configurations in order to test the 
different network protocols between the phone and my computer.


My conclusion is that there is only one way to have a working 
bidirectional data exchange: [tcpclient] on the phone and [tcpserver] on 
the computer. In all the other configurations (simple 
[netsend]/[netreceive] or [tcpsend]/[tcpreceive] for example) it was 
possible to send data from phone to computer but not from computer to 
phone. When I tried to invert the working configuration (putting a 
[tcpserver] on the phone), the following happened: the [tcpclient] on 
the computer seemed to be connected (outlet 2 was set to 1) but could 
not send (nor receive) any data to the phone.


Unfortunately, this does not enable me to have a direct connection 
between an external mobile application and ScenePlayer as I had hoped. I 
gave up momentarily with the idea of using network utilities, but I 
think that this is a question of interest for people working with Pd on 
Android: is there a reason for incoming TCP and UDP streams to be blocked?


Cheers

--
Gaël Dubus
Ph. D. student at KTH, Speech, Music and Hearing
Lindstedtsv. 24
S-10044  Stockholm (Sweden)
Mobile: +46(0)76 096 3411
Office: +46(0)8 790 7577
Fax:+46(0)8 790 7854

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

Re: [PD] pddroidparty netsend and netreceive

[berenger recoules]

Hi

in my experience, I managed to send data from Droidparty to my computer but
not the other way around, using the netro object by Chris.

you can check the netro object that uses netsend and netreceives :
http://code.google.com/p/pd-netro/

actually i also tried it on an iphone with rjdj and I can send data to the
iphone from my computer but not the other way around.

when I worked with it i'm not sure the version of pd used for libpd at this
time was 0.43. As Chris mentions in the google code, [netro] works with
0.43 and higher, it's maybe the time to give it another try.

cheers

Bérenger




2012/2/29 Orm Finnendahl 

> Hi,
>
>  I'm checking out pddroidparty for communication between an android
> device and a pd patch on another computer. It doesn't seem to be
> possible to send to or receive any events using the netsend and
> netreceive objects.
>
> I can ping both devices. Establishing a connection and sending numbers
> from the computer to a numberbox in the android patch gives no errors
> in the pd window on the computer, but the numbers aren't displayed on
> the device. The same happens sending data from the android to the
> computer. I can telnet the port on the android when pddroidparty runs
> the patch (and get a "connection refused" message if the patch has
> been closed) so it seems that there is no firewall blocking the
> communication.
>
> Does anybody know about this issue or has anybody successfully
> established netconnections between pddroidparty and another computer
> and could give some advice?
>
> --
> Orm
>
> ___
> 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] pddroidparty netsend and netreceive

[Orm Finnendahl]

Hi,

 I'm checking out pddroidparty for communication between an android
device and a pd patch on another computer. It doesn't seem to be
possible to send to or receive any events using the netsend and
netreceive objects.

I can ping both devices. Establishing a connection and sending numbers
from the computer to a numberbox in the android patch gives no errors
in the pd window on the computer, but the numbers aren't displayed on
the device. The same happens sending data from the android to the
computer. I can telnet the port on the android when pddroidparty runs
the patch (and get a "connection refused" message if the patch has
been closed) so it seems that there is no firewall blocking the
communication.

Does anybody know about this issue or has anybody successfully
established netconnections between pddroidparty and another computer
and could give some advice?

--
Orm

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

Re: [PD] latest Pd-Extended cpu usage (was: new editing features of Pd-extended 0.43, now in beta)

[Rich E]

Note that the issue I'm seeing is a difference in cpu usage between
Pd-Extended and Pd-vanilla.  In OS X 10.7, when opening up each version of
pd and looking at Activity Monitor (before every opening a patch or turning
on DSP), I get:

- Pd-0.43.1-extended-20120228 running at ~ 17% cpu
- Pd-0.43-1 running at ~ 7% cpu

I can file this on sourceforge if it would be easier to track there.

On Wed, Feb 29, 2012 at 8:56 PM, Jamie Bullock  wrote:

>
>
> On 28 Feb 2012, at 21:10, katja wrote:
>
> >
> >
> > On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock 
> wrote:
> >
> > Yup, I think this is related to the Portaudio driver. I reported it here:
> >
> >
> http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=55736&atid=478070
> >
> > I don't think it's Portaudio itself that's at fault, but rather the way
> it interfaces with Pd.
> >
> >
> > DspFuncLib is in:
> >
> >
>  
> /System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
> >
> > If you run command nm on the lib, you'll see a plethora of dsp functions
> like MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and
> whatnot. Functions in this lib are called when the internal soundcard is
> used. When using an external soundcard with Pd, DspFuncLib is not called
> and that makes the big difference in CPU load.
> >
> > AppleHDA and mach_kernel are Apple libs as well and together with
> DspFuncLib they are responsible for the crazy CPU load in the
> 'idle-but-dsp-on' case.
> >
> > PortAudio functions are apparently statically built into Pd and they
> consume very little CPU time.
> >
>
> It seems that you're right, so I've closed the bug (my apologies to
> PortAudio!).
>
> I guess the real 'fix' for this is that Pd now has a block size setting in
> Preferences. With a block size of 1024, using the PortAudio driver I get a
> CPU use of <2% with DSP on. Checking "use callbacks" also seems to reduce
> CPU. Here, I got a reduction of ~2% with that checked.
>
> Also, I'm not sure if this is an improvement in recent versions of OS X,
> but Pd now runs at only ~5% with DSP on using the PortAudio driver with a
> blocksize of 64. This is on a MacBook Air i7/1.8.
>
> best,
>
> Jamie
>
> --
> http://www.jamiebullock.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] latest Pd-Extended cpu usage (was: new editing features of Pd-extended 0.43, now in beta)

[Jamie Bullock]

On 28 Feb 2012, at 21:10, katja wrote:

> 
> 
> On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock  wrote:
> 
> Yup, I think this is related to the Portaudio driver. I reported it here:
> 
>
> http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=55736&atid=478070
> 
> I don't think it's Portaudio itself that's at fault, but rather the way it 
> interfaces with Pd.
> 
> 
> DspFuncLib is in:
> 
>  
> /System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
>  
> 
> If you run command nm on the lib, you'll see a plethora of dsp functions like 
> MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and whatnot. 
> Functions in this lib are called when the internal soundcard is used. When 
> using an external soundcard with Pd, DspFuncLib is not called and that makes 
> the big difference in CPU load.
> 
> AppleHDA and mach_kernel are Apple libs as well and together with DspFuncLib 
> they are responsible for the crazy CPU load in the 'idle-but-dsp-on' case. 
> 
> PortAudio functions are apparently statically built into Pd and they consume 
> very little CPU time.
> 

It seems that you're right, so I've closed the bug (my apologies to 
PortAudio!). 

I guess the real 'fix' for this is that Pd now has a block size setting in 
Preferences. With a block size of 1024, using the PortAudio driver I get a CPU 
use of <2% with DSP on. Checking "use callbacks" also seems to reduce CPU. 
Here, I got a reduction of ~2% with that checked.

Also, I'm not sure if this is an improvement in recent versions of OS X, but Pd 
now runs at only ~5% with DSP on using the PortAudio driver with a blocksize of 
64. This is on a MacBook Air i7/1.8.

best,

Jamie

--
http://www.jamiebullock.com

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