I fixed my wired mouse(was using hp wireless) , have 2 different keyboards
laptop and desktop, still with 64 bit dual core 2.2Ghz laptop with 4Gb ram
I get dropouts with xensynth even without moving the mouse. this does not
happen with miniwoog_1.0 downloaded from the forum site I think. I guess I
University of Florida, USA
(352)294-2020
From: pured...@11h11.com [pured...@11h11.com]
Sent: Wednesday, March 12, 2014 7:23 PM
To: Pagano, Patrick
Cc: pd-list@iem.at
Subject: Re: [PD] libpd and Unity
Would be useful to see the errors. Also what version of Unity
Excellent!
Btw someone reported that it's also working on Unity free osX version by:
- compiling libpdcsharp and then modify the loader_path execute:
- install_name_tool -id @loader_path/libpdcsharp.dylib libpdcsharp.dylib
- place in the root of Assets folder;
As for more example, I think
To: pd-list@iem.at
Subject: Re: [PD] libpd and Unity
Yes both adc / dac are working:
You can load a sample in a AudioSource, this will be the ADC signal
You can make a patch with a DAC, this will be the AudioListener
Communication from Unity - PD is working
Communication from PD - Unity is working
Would be useful to see the errors. Also what version of Unity (free /
pro) (3.5 / 4)?
Did you compile your own pdcsharlib.dll?
Windows: install mingw and compile libpd
(https://github.com/libpd/libpd) make csharplib. Copy
libs/libpdcsharl.dll to Assets/Plugins
à+
Hey
On Mit, 2014-03-12 at 19:23 -0400, pured...@11h11.com wrote:
[...]
How is it there in the future? :-)
Roman
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Yes both adc / dac are working:
You can load a sample in a AudioSource, this will be the ADC signal
You can make a patch with a DAC, this will be the AudioListener
Communication from Unity - PD is working
Communication from PD - Unity is working
Loading externals are working too. But what I do
to double
check that it's working.
On Mar 5, 2014, at 10:35 PM, pd-list-requ...@iem.at wrote:
From: Varun Nair nothingtok...@gmail.com
Subject: [PD] libpd and Unity
Date: March 5, 2014 at 6:16:05 PM EST
To: pd-list@iem.at
Hi all,
I extended Patrick Sebastien's work in libpd-4-unity
Yes, it was built from the master branch. The C# wrappers are used
across OSX, Android and Windows in Unity. Will test pd_045-4 next when I
get the time.
Cheers
Varun
--
@ntkeep http://twitter.com/ntkeep
re-sounding.com http://re-sounding.com
designingsound.org http://designingsound.org
Can you guys be clear about what is working? Pd audio in Unity? :-) crossing
fingers
Sent from my iPhone
On Mar 7, 2014, at 1:45 PM, Varun Nair
nothingtok...@gmail.commailto:nothingtok...@gmail.com wrote:
Yes, it was built from the master branch. The C# wrappers are used across OSX,
Android
Hi Varun,
thank you for this great tool! Is it possible to send events from PD to Unity
with this as well?
Best,
Filippo
Filippo Beck Peccoz - FBP
Game Audio Production
www.fbpsound.com
Studio: +49 (0)89-80033204
Fax: +49(0)89-99752164
Mobile: +49-(0)1520-4004143
Skype: fbpsound
On Mar 6,
Hi Filippo,
Yes! Works both ways. Messaging and audio related stuff has been tested.
Haven't got into MIDI and arrays yet.
Cheers
Varun
--
@ntkeep http://twitter.com/ntkeep
re-sounding.com http://re-sounding.com
designingsound.org http://designingsound.org
Filippo Beck Peccoz
Hi all,
I extended Patrick Sebastien's work in libpd-4-unity on Windows and now
have it working on OSX and Android. iOS is pending but will happen soon.
The whole API hasn't been tested, but basic functionality is in place
and works.
More info here
it's the overhead of the os that gets in the way, i started to try ofxpd
but found ofxui to be slow as all getout with my old machine.
what would be nice is someone fixing tcltk
On Thu, Feb 27, 2014 at 4:00 PM, Ivica Ico Bukvic i...@vt.edu wrote:
For instance, it seems like there are two
Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame
falls elsewhere.
enohp ym morf tnes
--
Dan Wilcox
danomatika.com
robotcowboy.com
On Feb 28, 2014, at 3:13 AM, Billy Stiltner billy.stilt...@gmail.com wrote:
it's the overhead of the os that gets in the
re:
Well, you're not using any tcl/tk if you're using libpd in ofxPd. The blame
falls elsewhere.
on slow machines it doesnt matter what gui you use there will be problems
is my point
so the best thing to do is fix tcl/tk
On Fri, Feb 28, 2014 at 7:40 AM, Dan Wilcox danomat...@gmail.com wrote:
For instance, it seems like there are two main concerns floating around:
a) multiple instances of pd
b) separating GUI from core
I would add a c) here which is what pd-l2ork has been doing, namely getting
rid of all known bugs and streamlining experience until it reaches a level
of
re:
:P Moreover, processors haven't gotten faster in a while
you can say that again!
I think it was 2005 I ordered the mayor of Appalachia a 3.2Ghz Intel CPU
17laptop. My current machine is only 2.2 Ghz.
On Tue, Feb 25, 2014 at 10:41 PM, Peter Brinkmann
peter.brinkm...@googlemail.com wrote:
Le 26/02/2014 04:41, Peter Brinkmann a écrit :
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
On 02/26/2014 12:53 PM, patrice colet wrote:
* pdvst (plugin for VST hosts) ?
that's a *perfect* usecase for libpd
fgmrdsa
IOhannes
signature.asc
Description: OpenPGP digital signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and
On 02/25/2014 10:41 PM, Peter Brinkmann wrote:
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
So to keep this from becoming yet another copy of a previous thread in the
archive, here's the thing: someone has to step up and say, I am going to
maintain 'core Pd'. That would mean listening to the needs of the
community, reviewing patches, and _delegating_ responsibilities.
Yes! I
While it would be incredibly pretentious of me to even think about
proposing pd-l2ork as an upstream standard, What I can share instead is
that I welcome all submissions and as was the case with patches submitted
so far we try to merge them quickly provided there are no major
showstoppers. Even if
On Wed, Feb 26, 2014 at 2:58 PM, Rafael Vega email.r...@gmail.com wrote:
It's been fascinating for me to see what has happened with OpenFrameworks
and their Do it with others philosophy. It would be great if the Pd
community would migrate into something similar.
What's interesting to me is
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
HI all -
My figure was 100K lines, not 10K. PD's C code is at about 70K now, and the
Tcl/TK code is 7K - so I am only adding expansions very carefully now.
Another related idea with an absurdly arbitrary round number attached: the code
is
built to last 50 years. It's now about 17 ywars in
On Wed, Feb 26, 2014 at 6:39 PM, Miller Puckette m...@ucsd.edu wrote:
HI all -
My figure was 100K lines, not 10K. PD's C code is at about 70K now, and
the
Tcl/TK code is 7K - so I am only adding expansions very carefully now.
Another related idea with an absurdly arbitrary round number
On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic i...@vt.edu 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
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
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely
Pd-vanilla + externals.
I don't think it needs to be sad. Yes, pd-extended is
From: Dan Wilcox [mailto:danomat...@gmail.com]
Sent: Monday, February 24, 2014 11:34 AM
To: Ivica Bukvic
Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann
Subject: Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote
; Peter Brinkmann
Subject: Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote:
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely
Pd-vanilla
Wilcox [mailto:danomat...@gmail.com]
*Sent:* Monday, February 24, 2014 11:34 AM
*To:* Ivica Bukvic
*Cc:* Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann
*Subject:* Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote:
On Sun, Feb 23
Bukvic i...@vt.edu wrote:
From:Dan Wilcox [mailto:danomat...@gmail.com]
Sent: Monday, February 24, 2014 11:34 AM
To: Ivica Bukvic
Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann
Subject: Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu
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
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current
single-threaded implementation that would be measurably improved by using a
multi-threaded approach?
Ask any of the people who have to run two instances of
Also, to be honest, at this point if Cycling 74 came out with Max runtimes for
iOS and Linux, I would probably switch. I don't say that because I don't like
PD, but more from a pragmatic point of view where I consider which project is
currently progressing in the long term.
For instance, on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ok, Dan, i can feel you there. but let's not mix up the GUI-core
separation with the GEM on OS X question. As much as their
consequences are similar, they are fundamentally different in their
implementation, no?
Questions that comes to my mind when I
On Feb 23, 2014, at 12:14 PM, Max abonneme...@revolwear.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ok, Dan, i can feel you there. but let's not mix up the GUI-core
separation with the GEM on OS X question. As much as their
consequences are similar, they are fundamentally
Hi all - just a short note since this discussion is much too wode-ranging to
address in full...
2. Would the result of this work be accepted by Miller and become vanilla?
As history has shown, the chances are limited. Again, there is probably a
good way to do it where you could choose
Well, then I'm simply out of the loop and mostly-off base. Woops, sorry. I'll
go there and see if we can keep it going. Looks like we're talking about both
multi-threading and multi-instances which would be a big move towards solving
some fundamental problems.
Also, it's not really a
On 02/23/2014 07:37 AM, Dan Wilcox wrote:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current
single-threaded implementation that would be measurably improved by using a
multi-threaded approach?
Ask any of
On 23 Feb 2014, at 20:29, Jonathan Wilkes jancs...@yahoo.com wrote:
Things maybe acceptable to us PD grey beards, but at some point it would
be nice to find a way to enter the modern, multicore multithreaded world.
Moores law has shifted from clock speed to just add more cores years ago
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 02/23/2014 07:37 AM, Dan Wilcox wrote:
On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
Do you have an example of a patch that suffers from Pd's current
single-threaded implementation that would
On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox danomat...@gmail.com wrote:
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
Yeah, stuff like that we should be able to solve. I'm not for ditching the
Tcl/Tk gui at all. The work you and Ivica have been doing seems to be
Hey lets keep on topic here. :) I'd say separating the gui and core is much
less work than trying to revamp pd's threading model. Just *enabling*
thirdparty
GUI's that can talk to pd core as an audio and computation engine, should
be possible without breaking backwards compatibility.
On 02/23/2014 08:15 PM, Ivica Bukvic wrote:
On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox danomat...@gmail.com
mailto:danomat...@gmail.com wrote:
On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
Yeah, stuff like that we should be
Coming back on topic:
On Feb 23, 2014, at 8:15 PM, Ivica Bukvic i...@vt.edu wrote:
If I may chime in for a sec (pd-l2ork author here), there is absolutely no
interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already
has thousands of lines of code either altered or added
libpd requires a lot of what pd-l2ork offers in order to be able to move
forward (obeying stacking order for instance, that are a prerequisite for
global system-wide presets as well as editing tools like undo/redo and
tofront/back). pd-l2ork also improves on pack, route, select, and trigger
to
On Feb 23, 2014, at 10:46 PM, Ivica Bukvic i...@vt.edu wrote:
libpd requires a lot of what pd-l2ork offers in order to be able to move
forward (obeying stacking order for instance, that are a prerequisite for
global system-wide presets as well as editing tools like undo/redo and
On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote:
I consider that a sad thing. At least with Pd-extended, it was largely
Pd-vanilla + externals.
I don't think it needs to be sad. Yes, pd-extended is pd-vanilla +
externals + most limitations of the vanilla. How does
On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 02/20/2014 09:50 PM, Rich E wrote:
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancs...@yahoo.comwrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox
I'm just having trouble with the specifics. Do you have an example of a patch
that suffers from Pd's current single-threaded implementation that would be
measurably improved by using a multi-threaded approach? Also, what is the
metric to use here?
To compare apples to apples, imagine that
On 02/20/2014 09:50 PM, Rich E wrote:
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com
mailto:danomat...@gmail.com
Hi,
just to give some example of single vs multi-threaded, and some
comparison points.
- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded
programming, even on multi-core computers. BUT they handle a much
reduced number of use
On 21/02/14 20:41, Charles Goyard wrote:
Hi,
just to give some example of single vs multi-threaded, and some
comparison points.
- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded
programming, even on multi-core computers.
Hi,
In the case of PD, maybe just a good mix of libpd and a generalization
of pd~ can improve things much.
[pd~] deals with the particular case of creating an extra dsp thread, it
incurs overhead to do so and does not isolate the dsp from a busy patch. It
is quite orthogonal to creating
On 02/21/2014 06:41 AM, Simon Wise wrote:
On 21/02/14 20:41, Charles Goyard wrote:
Hi,
just to give some example of single vs multi-threaded, and some
comparison points.
- projects like haproxy and lighthttpd show that good state
machine programming can be more efficient that multi-threaded
On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancs...@yahoo.comwrote:
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how
it determines execution order
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2014-02-17 22:42, Jonathan Wilkes wrote:
No sane person is going to do incremental work without a plan on
GUI software in 2014 that only has a single undo.
luckily the work on the GUI will most likely happen in git, which
gives you infinite
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how it
determines execution order or independent blocks of objects right?
On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomat...@gmail.com wrote:
Does the
On 02/18/2014 04:00 AM, IOhannes m zmoelnig wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2014-02-17 22:42, Jonathan Wilkes wrote:
No sane person is going to do incremental work without a plan on
GUI software in 2014 that only has a single undo.
luckily the work on the GUI will
On 02/18/2014 11:11 PM, Rich E wrote:
On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com
mailto:danomat...@gmail.com wrote:
Ah wait, duh. Of course the graph needs to know positioning,
that's how it determines execution order or independent blocks of
objects
I think that the way forward with the pd/gui separation is to work on the low
hanging fruit, things that are easy to fix. Let the hard parts for later,
which will only be a couple areas.
So that means looking at everywhere where sys_gui() or sys_vgui() is called,
and seeing how the raw Tcl
On 02/17/2014 10:48 AM, Hans-Christoph Steiner wrote:
I think that the way forward with the pd/gui separation is to work on the low
hanging fruit, things that are easy to fix. Let the hard parts for later,
which will only be a couple areas.
So that means looking at everywhere where sys_gui()
On 13/01/2014 15:32, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to
perhaps solve the PD gui development doesn't move fast enough problem
in the long term. In this case, Miller would have the core (in libpd)
the pd-vanilla wrapper gui formally separated
As Hans has proposed for years, IMO this is really the only way to perhaps
solve the PD gui development doesn't move fast enough problem in the long
term. In this case, Miller would have the core (in libpd) the pd-vanilla
wrapper gui formally separated while everyone else can then use the same
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to
perhaps solve the PD gui development doesn't move fast enough
problem in the long term. In this case, Miller would have the core (in
libpd) the pd-vanilla wrapper gui formally
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps
solve the PD gui development doesn't move fast enough problem in the long
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to
perhaps solve
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote:
Sorry, I don't know quite what you're referring to here. The only two
Ah wait, duh. Of course the graph needs to know positioning, that's how it
determines execution order or independent blocks of objects right?
On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomat...@gmail.com wrote:
Does the dsp graph rely on positioning? I thought only via connections. I'd
On 01/13/2014 05:14 PM, Dan Wilcox wrote:
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com
mailto:jancs...@yahoo.com wrote:
On 01/13/2014 03:11 PM, Dan Wilcox wrote:
Woops, forgot the reply-all.
On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com
Hello all,
I have been setting up my libpd project exactly as described in the Making
Musical Apps book, but keep getting an error that z_queued.h can't be
found...does anyone have any tips or suggestions?
Thanks!
Nick
--
Nicholas Arner
MSc in Music Technology by Research
Department of
Hey Nick
Let me know how you get on I just bought Making musical apps as well and I
would love to mirror the how to with someone else. I have 10.8.5 and Xcode5
Sent from my iPhone
On Nov 27, 2013, at 10:04 AM, Nick Arner nicholasar...@gmail.com wrote:
Hello all,
I have been setting up
Hi List and LibPD developers !
Testing an iOS app with LibPD we get: unknown audio API specified
Is it a PD patch problem or xCode ? or what can it be ? the Pd-patch works well
in Vanilla.
any advice please
thanks !
___
Pd-list@iem.at mailing
Most likely, you haven't specified the dummy audio api via compiler defines.
See https://github.com/libpd/libpd/wiki/libpd#build-settings
On Aug 26, 2013, at 6:00 AM, pd-list-requ...@iem.at wrote:
From: Фывапр Олджэвич tofuc...@inbox.ru
Subject: [PD] libPD : unknown audio API specified
Hi list!
I'm aware that libpd and Processing are not the subjects more related to
this list but I've asked this were it's suposed to be; Pd-everywhere 's
threat at Create Digital Noise without any reply by now, so I'm trying it
here.
Libpd and Processing work really fine together and embedding PD
, pd-list-requ...@iem.at wrote:
From: Òscar Martínez Carmona xamp...@gmail.com
Subject: [PD] libpd and Processing; handling externals
Date: August 5, 2013 2:14:43 AM EDT
To: pd-list@iem.at pd-list@iem.at
Hi list!
I'm aware that libpd and Processing are not the subjects more related
Martínez Carmona xamp...@gmail.com
*Subject: **[PD] libpd and Processing; handling externals*
*Date: *August 5, 2013 2:14:43 AM EDT
*To: *pd-list@iem.at pd-list@iem.at
Hi list!
I'm aware that libpd and Processing are not the subjects more related to
this list but I've asked this were it's
...@gmail.com
*Subject: **[PD] libpd and Processing; handling externals*
*Date: *August 5, 2013 2:14:43 AM EDT
*To: *pd-list@iem.at pd-list@iem.at
Hi list!
I'm aware that libpd and Processing are not the subjects more related to
this list but I've asked this were it's suposed to be; Pd-everywhere
Howdy guys,
See https://github.com/danomatika/ofxPd#for-xcode-1
From my notes, I have: -DHAVE_UNISTD_H -DUSEAPI_DUMMY -DPD -dynamiclib -ldl -lm
I also added this to the libpd Github wiki:
https://github.com/libpd/libpd/wiki/libpd#build-settings
On Jul 11, 2013, at 11:45 AM, Ed Kelly
Hi Dan, Peter,
I'm here with our ofxPd-based iPhone app, and we are getting a repeat of a
particular problem listed here:
http://createdigitalnoise.com/discussion/150/pdbase-closepatch/p1
Namely:
when closing a patch I would receive this message: sys_close_audio: unknown
API 9
and then we
Hi Dan,
Thanks for quick response. Even with these compiler flags, we get the same
result. On the same page there is this:
RtAudio Hang on Exit in 0062
RtAudio will hang on app exit in OF 0062. The only way to fix this is to make
a small edit to the OF 0062 core by editing
You could try the 007 tag: https://github.com/danomatika/ofxPd/releases,
everything after that will not work without some src modifications. (It may not
be that much).
Personally, I would consider updating your version of OF. You'd need to remake
the xcode project, but the sound stuff is in a
Hi Dan,
Thanks for your help. I know they're holding off the rewrite in OF 7 due to
time and budgetary constraints, but we think there was another reason why it
kept hanging.
A, external I wrote in C gives out sample accurate events (rather that
block-aligned ones) as well as a signal. The
wrote:
*From: *Joe White white.j...@gmail.com
*Subject: **[PD] Libpd running in OS X app*
*Date: *July 5, 2013 7:34:47 AM EDT
*To: *pd-list pd-list@iem.at
Hi guys,
Does anyone have any experience running libpd in an OS X app, using
CoreAudio.
I'm able to run a patch and receive print
wanna help out there or sponsor us? :D
On Jul 5, 2013, at 7:56 AM, pd-list-requ...@iem.at wrote:
*From: *Joe White white.j...@gmail.com
*Subject: **[PD] Libpd running in OS X app*
*Date: *July 5, 2013 7:34:47 AM EDT
*To: *pd-list pd-list@iem.at
Hi guys,
Does anyone have any experience
-requ...@iem.at wrote:
*From: *Joe White white.j...@gmail.com
*Subject: **[PD] Libpd running in OS X app*
*Date: *July 5, 2013 7:34:47 AM EDT
*To: *pd-list pd-list@iem.at
Hi guys,
Does anyone have any experience running libpd in an OS X app, using
CoreAudio.
I'm able to run a patch
danomat...@gmail.com wrote:
As far as I know, the OSX port isn't finished and the CoreAudio backend
isn't hooked up. Anyone wanna help out there or sponsor us? :D
On Jul 5, 2013, at 7:56 AM, pd-list-requ...@iem.at wrote:
*From: *Joe White white.j...@gmail.com
*Subject: **[PD] Libpd running
, 2013, at 7:56 AM, pd-list-requ...@iem.at wrote:
From: Joe White white.j...@gmail.com
Subject: [PD] Libpd running in OS X app
Date: July 5, 2013 7:34:47 AM EDT
To: pd-list pd-list@iem.at
Hi guys,
Does anyone have any experience running libpd in an OS X app, using
CoreAudio.
I'm
...@gmail.com wrote:
As far as I know, the OSX port isn't finished and the CoreAudio backend
isn't hooked up. Anyone wanna help out there or sponsor us? :D
On Jul 5, 2013, at 7:56 AM, pd-list-requ...@iem.at wrote:
*From: *Joe White white.j...@gmail.com
*Subject: **[PD] Libpd running in OS X app
Hi guys,
Does anyone have any experience running libpd in an OS X app, using
CoreAudio.
I'm able to run a patch and receive print statements but I'm not getting
any audio output and DSP doesn't seem to be processing. I created a quick
test tone in code to see if it was my audio unit but that
As far as I know, the OSX port isn't finished and the CoreAudio backend isn't
hooked up. Anyone wanna help out there or sponsor us? :D
On Jul 5, 2013, at 7:56 AM, pd-list-requ...@iem.at wrote:
From: Joe White white.j...@gmail.com
Subject: [PD] Libpd running in OS X app
Date: July 5, 2013 7
If someone wanted to libpd-ify the Pd-extended core, I'll help where I can.
That would give you things like [initbang], $@ and $#, the 'blob' type for
handling generic blobs of memory, and more.
.hc
On 02/21/2013 12:39 AM, Peter Brinkmann wrote:
libpd itself only tracks Pd Vanilla, but you can
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
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
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
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 billy.stilt...@gmail.comwrote:
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
I m familiar with the PD comport object but my patch is running on a mobile
phone and i can't access the console message logs :-(
Maurin
Le 7 janv. 2013 à 05:35, Martin Peach a écrit :
On 2013-01-06 15:13, Maurin Donneaud wrote:
Im trying to connect Arduino via bluetooth to libPd /
1 - 100 of 153 matches
Mail list logo
