Re: [PD-dev] Multiple Instance of pdlib

Good point. I wasn't involved when Peter first started the project and I'm > sure, back then, multiple PD instances seemed waaay off into the future. > That's not actually what I was thinking when I was putting together the API of libpd. My goal was simply to create the thinnest possible wrapper i

Re: [PD-dev] sysex/midiin and port numbers

> cheers > Miller > > On Tue, Jan 08, 2013 at 01:06:41PM -0800, Miller Puckette wrote: > > I _think_ it would be safe to change this... anyone know of any way that > > would break compatibility? > > > > thanks > > M > > > > On Tue, Jan 08, 2013

Re: [PD-dev] [PD] libpd netreceive

audio, at least for iOS. > Maybe introducing a sys_microsleep(0,1) in the audio callback does the > trick? I will test that now. > That said, i'm totally unaware of the details of other implementations. > > all the best, > gr > > > > 2013/1/21 Peter Brinkmann

[PD-dev] sysex/midiin and port numbers

Hi, I've been revisiting the MIDI support of libpd, and I noticed that the functions inmidi_byte and inmidi_sysex add one to the port number before passing the message on to the midiin/sysexin object. Is this the desired behavior? If so, why? If not, is it too late to change it? I also don't under

Re: [PD-dev] Filter design for iPhone

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

Re: [PD-dev] Filter design for iPhone

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 filin

Re: [PD-dev] fontwidth and nogui

to report the > northwest corner but the entire rectangle, which depends on font size. > > Anyway, yes, I'm fixing a couple of bugs and will change that -- it sounds > quite safe to me. > > cheers > Miller > On Sun, Feb 19, 2012 at 09:18:00AM -0800, Peter Brinkmann wrote:

[PD-dev] fontwidth and nogui

Hi, A recent thread on Pd Everywhere suggests that the function rtext_senditup in g_rtext.c sometimes divides by a font width. This causes occasional crashes because the font width may be 0 when running with the nogui flag: http://noisepages.com/groups/pd-everywhere/forum/topic/any-issues-with-sub

Re: [PD-dev] Fwd: per-thread storage in Pd in support of pdlib - discussion?

On Sat, Feb 4, 2012 at 10:20 PM, Hans-Christoph Steiner wrote: > The way I see the "editing API" is the converse of the pd-gui --> pd > communications: pd messages.  My approach is to do it bit by bit.  Take a > chunk of the current pd-gui --> pd communications and refactor into > something that l

Re: [PD-dev] Fwd: per-thread storage in Pd in support of pdlib - discussion?

On Thu, Feb 2, 2012 at 1:52 AM, Rich E wrote: > I do think it is important to separate these things into bite size chunks > (I think IOhannes mentioned this as well during his LAC talk). Peter, your > blog post talks of creating an API for editing patches > (here

Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?

> I see the next important step as making the general cases easier to > handle. A per-thread context such as IOhannes and Peter describe above > seems like the best approach to allowing a program to run multiple > instances of pd in a much more predictable manner, while it still allows > for backw

Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?

On Wed, Jan 25, 2012 at 5:38 PM, Charles Henry wrote: > On Wed, Jan 25, 2012 at 11:46 AM, Peter Brinkmann > wrote: > > > > Hi Chuck, > > Check out the early bits of this thread --- various use cases already > came > > up along the way: > > http://lists

Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?

Hi Chuck, Check out the early bits of this thread --- various use cases already came up along the way: http://lists.puredata.info/pipermail/pd-dev/2012-01/017992.html. The short version is that libpd is being used in such a wide range of settings that you can come up with legitimate use cases for

[PD-dev] per-thread storage in Pd in support of pdlib - discussion?

Oops, I just realized that I sent my reply IOhannes and didn't cc pd-dev... On Thu, Jan 19, 2012 at 4:11 AM, IOhannes m zmoelnig wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >> right now, only #1 is possible at all and it takes some effort on the > > >> "thread host" (the exter

Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?

On Mon, Jan 16, 2012 at 3:43 AM, IOhannes m zmoelnig wrote: > > i think there are 2 use cases for multi "threading". > > #1 access a single instance of (lib)pd from multiple threads > #2 allow multiple instances of (lib)pd to co-exist in global memory. > That's right, and there are real use cases

Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?

Hi Miller, Thanks for your message! I'm afraid thread-local instances would be problematic from the point of view of libpd: * The most common structure of a libpd-based application involves two threads, a GUI thread and an audio thread, where the GUI controls the Pd engine by invoking libpd funct

Re: [PD-dev] libpd crasher bug from recent change to glist_delete()

Hi Miller, Thanks for taking care of this so quickly! I merged the latest change and it works. All is well in libpd-land. Cheers, Peter On Sat, Nov 26, 2011 at 8:08 PM, Miller Puckette wrote: > Hi Rich and all - > > I think I've tracked that down and fixed it... I just now pushed the chang

Re: [PD-dev] Debugging PdLib on iPod Touch

Hi Chris, Regarding the sample rate problem on older iPods, I would try to find an audio project that works properly on an iPod Touch 2G and see how its setup code differs from that in PdAudio. Other than that, I'm afraid I don't have much of an idea because I don't know much about iPhone developm

Re: [PD-dev] Pdlib - sensors

Hi Alexandre, The philosophy of libpd is that Pd is supposed to do audio processing and audio processing only, and communication between libpd and client code happens via Pd messages. Anything else, such as handling sensor input, is the responsibility of the client code. Cheers, Peter On Sa

Re: [PD-dev] pdlib: unknown audio API specified

Hi Chris, Richard Lawler generously donated a test project for Xcode to libpd. I just added it to the repository at http://gitorious.org/pdlib. The Xcode project lives in pd-for-android/PdCore/jni/src/objc/PdTest01. The file PdTest01/ReadMe.txt explains how to set it up. Best, Peter On T

Re: [PD-dev] End of iPd hiatus

Hi Chris, The new libpd is a C library that gently attaches itself to the existing code base, requiring only minimal changes, the most important of which have already been accepted into the official version of pd. On top of the C library there is some JNI glue for using libpd with Java (or Process

Re: [PD-dev] [PD-Dev] : compiling pd-extended for Gentoo 64bits.

*86-*-linux*) > > to this: > > *86*-linux*) > > Then that should work for both x86 and x86_64. > Actually, the code for the targets is not quite the same; I had to add -fPIC to the compiler options to get it to compile on my 64-bit machine. Peter > On Mar 11,

[PD-dev] [PD-Dev] : compiling pd-extended for Gentoo 64bits.

Hi all, I recently managed to compile OSCx on my 64-bit machine (FC6 with Planet CCRMA) by adding the appropriate compiler options to configure.ac. I'll attach the modified file. By the way, I'm about to embark on a project that'll probably involve PD and OSC. I'm getting the impression that I s