Thanks Tom/Frank/Akira Abe for your replies,
firstly if I find any solution to life as we know it I promise I will let you know... My usage of pd is not music based so I'm sure I would be unwise to go down the VST plugin route, the other pieces of s/w that I want to use involve C/C++ APIs, interfaces implemented in a very similar way to those in the DirectSound API itself, interfaces which support COM objects - thus my highly windows restricted application (although it is promised that COM objects will be portable in the future???)... ... also my resources are limited....so I am trying (I suppose) to use functional C/C++ chunks of pd that I can insert into the controlling VC++ application. I don't require the GUI part of pd and therefore do not want pd to run as is, possibly I could use STK more easily in this fashion but pd seems to have more of what I require. It seems to me that through portaudio pd is creating the DirectSound COM objects, through the API, and once created surely I can use them?
Its Sunday and I am possibly more than a little confused....
thanks again - everything/ anything is a great help
ps how would using Linux help me get a license for ReWire? pps Jack is interesting, how do I get info on the linux interface? ppps am I on the wrong list?! (pd-list not pd-dev??)
Mandy
MLN Kazem, Aerospace Engineering M.Kazem@bristol.ac.uk Tel. 0117 9288219 Fax. 0117 9272771
Hi..
you might be better off just coding your own object based modular dsp system and then using that system in yr app.. I have done this myself and it isn't as hard as it seems(in c++ using portaudio n midi), as the basis for most dsp objects is simple.. its the connectivity that can be a pain... This way though you could just use code from individual pd units as a starter point...? You just need to set up the basic dsp object template and then derive and use some sort of pointer system for flow and structure..
Tom
----- Original Message ----- From: MLN Kazem, Aerospace Engineering M.Kazem@bristol.ac.uk To: pd-list@iem.kug.ac.at Sent: Sunday, September 29, 2002 7:14 PM Subject: [PD] using other s/w with pd
Thanks Tom/Frank/Akira Abe for your replies,
firstly if I find any solution to life as we know it I promise I will let you know... My usage of pd is not music based so I'm sure I would be unwise to go down the VST plugin route, the other pieces of s/w that I want to use involve C/C++ APIs, interfaces implemented in a very similar way to those in the DirectSound API itself, interfaces which support COM objects - thus my highly windows restricted application (although it is promised that COM objects will be portable in the future???)... ... also my resources are limited....so I am trying (I suppose) to use functional C/C++ chunks of pd that I can insert into the controlling VC++ application. I don't require the GUI part of pd and therefore do not want pd to run as is, possibly I could use STK more easily in this fashion but pd seems to have more of what I require. It seems to me that through portaudio pd is creating the DirectSound COM objects, through the API, and once created surely I can use them?
Its Sunday and I am possibly more than a little confused....
thanks again - everything/ anything is a great help
ps how would using Linux help me get a license for ReWire? pps Jack is interesting, how do I get info on the linux interface? ppps am I on the wrong list?! (pd-list not pd-dev??)
Mandy
MLN Kazem, Aerospace Engineering M.Kazem@bristol.ac.uk Tel. 0117 9288219 Fax. 0117 9272771
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi all,
thanks for that...could I possibly pester for more info.... I have
always assumed that developing the bones of a dsp system itself would
be very complex producing lots of niggling issues that take ages to
iron out...as it seems that several people have successfully built such
systems surely it's best to use their implementations as opposed to
trying to rewrite basic parts of their code for my own (inevitably
inferior) system??? Would it really be possible in a relatively short
period of time???...any more clues Tom would be great....
Could anyone point me towards any links/sites to give an overview of control flow through the C code behind pd, I'm piecing together what I can from the code and the way (obviously) I can see pd work through the GUI, but any info would be great here simply to improve my understanding.
On a final push for more info.....the reason I wanted to pursue pd was firstly because it has functionality such as ffts et.c. (which I think STK does not) and secondly because it would have been nice to rapidly prototype my ideas with pd using its ready-to-use gui (so I could have more of a feel for what I was producing) and then having produced the patches I required, dispense with the gui and implement the functionality within a C++ app driven with my own C++ data....on the output side of things I'm fairly sure its possible (looking at portaudio for directsound) to extract the resulting information passed into the secondary directsound buffers for my own purposes.
On Sun, 29 Sep 2002 20:02:02 +0100 nullpointer nullpointer@odessadesign.co.uk wrote:
Hi..
you might be better off just coding your own object based modular dsp system and then using that system in yr app.. I have done this myself and it isn't as hard as it seems(in c++ using portaudio n midi), as the basis for most dsp objects is simple.. its the connectivity that can be a pain... This way though you could just use code from individual pd units as a starter point...? You just need to set up the basic dsp object template and then derive and use some sort of pointer system for flow and structure..
Tom
----- Original Message ----- From: MLN Kazem, Aerospace Engineering M.Kazem@bristol.ac.uk To: pd-list@iem.kug.ac.at Sent: Sunday, September 29, 2002 7:14 PM Subject: [PD] using other s/w with pd
Thanks Tom/Frank/Akira Abe for your replies,
firstly if I find any solution to life as we know it I promise I will let you know... My usage of pd is not music based so I'm sure I would be unwise to go down the VST plugin route, the other pieces of s/w that I want to use involve C/C++ APIs, interfaces implemented in a very similar way to those in the DirectSound API itself, interfaces which support COM objects - thus my highly windows restricted application (although it is promised that COM objects will be portable in the future???)... ... also my resources are limited....so I am trying (I suppose) to use functional C/C++ chunks of pd that I can insert into the controlling VC++ application. I don't require the GUI part of pd and therefore do not want pd to run as is, possibly I could use STK more easily in this fashion but pd seems to have more of what I require. It seems to me that through portaudio pd is creating the DirectSound COM objects, through the API, and once created surely I can use them?
Its Sunday and I am possibly more than a little confused....
thanks again - everything/ anything is a great help
ps how would using Linux help me get a license for ReWire? pps Jack is interesting, how do I get info on the linux interface? ppps am I on the wrong list?! (pd-list not pd-dev??)
Mandy
MLN Kazem, Aerospace Engineering M.Kazem@bristol.ac.uk Tel. 0117 9288219 Fax. 0117 9272771
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
MLN Kazem, Aerospace Engineering M.Kazem@bristol.ac.uk Tel. 0117 9288219 Fax. 0117 9272771
Hi, MLN Kazem, Aerospace Engineering hat gesagt: // MLN Kazem, Aerospace Engineering wrote:
... also my resources are limited....so I am trying (I suppose) to use functional C/C++ chunks of pd that I can insert into the controlling VC++ application. I don't require the GUI part of pd and therefore do not want pd to run as is, possibly I could use STK more easily in this fashion but pd seems to have more of what I require.
Maybe a library like STK or SndObj is better for this kind of approach. In my view PD isn't much of a real code library to use in writing other programs, it's more, that you can use a lot of other libraries in PD, because PD is a wide open system.
ps how would using Linux help me get a license for ReWire?
Not at all, there is no ReWire for Linux. But using Linux would very much free one of worrying about getting licenses for software, because most of it is Free Software. But as you wrote above, switching to Linux is not an option.
pps Jack is interesting, how do I get info on the linux interface?
ppps am I on the wrong list?! (pd-list not pd-dev??)
Actually yes, but all pd developers also read this list, I'm sure.
Frank Barknecht _ ______footils.org__
On Mon, 30 Sep 2002, Frank Barknecht wrote:
pps Jack is interesting, how do I get info on the linux interface?
OAT, I have been looking at Boodler http://www.eblong.com/zarf/boodler/ ,n a programmable sounscape tool which lets you script sound agents in Python, both because it's a lot of fun, and because I'm using it to learn Python. My intention was to use it with pd, but I've got problems:
(bleargh)
I realised boodler can be compiled to talk alsa, oss or esd. This makes me think it could (if I was better at Python right now) talk Jack.
like to drive the soundscape agent interaction through midi data), but it seems SUCH a waste to drop pd and its large library of sound objects and in-built midi handling just to gain control of a small bunch o'python.
Ended up just using pd as midi control with netsend (boodler talks tcp), but as said above, that misses the -largest- part of pd wonderfulness.
So, my question: Could anybody out here (Thomas?) take a look at Boodler and give me some pointers as to the chances/degree of insanity involved in forcing it to talk to pd, either through pyext or through Jack? It would speed things up for me in trying to decide which way to go, and what to read up on. Any advice on Jack/Pd in how-to form would be greatly appreciated too...
My ultimate aim is to cross-breed boodler with some of the AIMA python code http://www.norvig.com/python/python.html since it's already agent-based, then run with pd to do real-time mongering + playing.
Running pd debian package 0.32p1-5_powerpc.deb on woody 2.4.18 ppc (pismo G3) and Thomas Grill's latest pyext (thank you!) through OSS debian defaults.
Sorry 'bout long rant.
dc
www.ariada.uea.ac.uk/~dcasal --)+
Hi David, hi all,
So, my question: Could anybody out here (Thomas?) take a look at Boodler and give me some pointers as to the chances/degree of insanity involved in forcing it to talk to pd, either through pyext or through Jack?
i had a look and i have to say that Boodler is well-designed concerning the modularity of sound output facilities. In order to use Jack one does just have to write the appropriate audev-jack.c interface functions. This should be fairly easy. To be used in PD this whole "cboodle" python interface module has to be built into a pd external.
The latter of course takes us to another level. If sample computation be realized in a Python external, how should the API look like? I haven't spent much of a thought on that but now i see the possibilities - thank you for the pointer, David! For a general approach the Boodler interface style doesn't seem to be well fitted... it only supports 2 channels and 16 bits. I think i study the stuff a bit more and then try to implement a general signal interface for pyext (which could in a further step be specialized for the Boodler case).
best greetings, Thomas
On Thu, 3 Oct 2002, Thomas Grill wrote:
Hi Thomas and everybody,
So, my question: Could anybody out here (Thomas?) take a look at Boodler and give me some pointers as to the chances/degree of insanity involved in forcing it to talk to pd, either through pyext or through Jack?
In order to use Jack one does just have to write the appropriate audev-jack.c interface functions. This should be fairly easy.
Alas, my C blows goats. Maybe it's worth cracking 'Thinking in C' open? (though my head hurts from Python already)
To be used in PD this whole "cboodle" python interface module has to be built into a pd external.
Ahhh. Hmmmm.
The latter of course takes us to another level. If sample computation be realized in a Python external, how should the API look like?
Indeed!
I haven't spent much of a thought on that but now i see the possibilities - thank you for the pointer, David!
Er, no problem. Really wish I could -actually- help...
For a general approach the Boodler interface style doesn't seem to be well fitted... it only supports 2 channels and 16 bits.
True, and I can't for the life of me find how to change that, which makes me think it would be best to dispense with the whole sound bit for boodler and implement it instead as a pd objectt, as you say.
I think i study the stuff a bit more and then try to implement a general signal interface for pyext (which could in a further step be specialized for the Boodler case).
YAY! Please let me know if I can help (what to read, how to crack my head against the wall, whatever)
Thank you once again for your help!
d
www.ariada.uea.ac.uk/~dcasal --)+
On Thu, 3 Oct 2002, david casal wrote:
read up on. Any advice on Jack/Pd in how-to form would be greatly appreciated too...
Hi David,
I have folded the patches into the unofficiallissimo pd CVS repository:
Here is the way to access it:
cvs -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data login
cvs -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data get -r devel_0_35 pd
[additional possibilities] Instead of the devel_0_35 you could also put jack_0_35_0_cb (which only gives you the callback based jack implementation), or jack_0_35_0_fifo which should give you a pd with the fifo based implementation.
The devel_0_35 gives you Josephs shadow patch and jack fifo. [/additional possibilities]
Please, please, if you try this, be aware that it is unofficial.
Then you have to go to the jackit.sf.net and install jack and configure pd with ./configure --enable-jack
Greetings,
Guenter
Hi all,
Trying to to PD-->Jack. Ran into trouble:
I'm running Debian 2.4.18 on a powerbook (pismo G3). Got the CVS pd version of devel_0_35 and compiled with './configure --enable-jack --enable-alsa'.
Checked out Jack (CVS), tinkered with configure.in until autogen worked.
tried to start jack with 'jackd -d alsa -d screamer', and it seemed fine:
loading driver .. creating alsa driver ... screamer|1024|2|48000|swmon starting engine
I've got a .asoundrc with:
pcm.screamer { type hw card 0 }
(aplay -l says: card 0: card0 [PowerMac Screamer], device 0: PMac Screamer)
then tried to start PD with:
pd -jack -verbose
PD's output:
Pd version 0.35 (MIDI stuff) using jack interface cannot read event connect result from server (No such device) cannot connect to server for event stream (No such device) (last 2 lines repeated 5 times) jack server not running?
Jack's output:
**** alsa_pcm: xrun of at least 4.253 msecs
unknown client ID in ACK connection request cannot complete client ACK connection process (last 2 lines repeated 5 times)
</output_stuff>
Thing is, I had quite a bit of trouble compiling ALSA for this powerbook, and I fear maybe the thing's gone mad...but I'm able to 'modprobe modprobe snd-powermac Any clues, anybody?
SOrry about long message.
cheers, david
Please, please, if you try this, be aware that it is unofficial.
Then you have to go to the jackit.sf.net and install jack and configure pd with ./configure --enable-jack
Greetings,
Guenter
www.ariada.uea.ac.uk/~dcasal --)+
Hi, david casal hat gesagt: // david casal wrote:
I'm running Debian 2.4.18 on a powerbook (pismo G3). Got the CVS pd version of devel_0_35 and compiled with './configure --enable-jack --enable-alsa'.
Checked out Jack (CVS), tinkered with configure.in until autogen worked.
I really can recommend the Debian-jack packages. The maintainer is doing a great work to stay up to date with Jack-CVS and if you enable capabilites support you can even run Jack as a normal user and still get high scheduling and low latency using the "jackstart" app in the Debian package.
Frank Barknecht _ ______footils.org__
On Tue, 22 Oct 2002, Frank Barknecht wrote:
I really can recommend the Debian-jack packages. The maintainer is doing a great work to stay up to date with Jack-CVS and if you enable capabilites support you can even run Jack as a normal user and still get high scheduling and low latency using the "jackstart" app in the Debian package.
Well after some grief with alsa rc3 for ppcc arch, debian packages for Jack were indeed my salvation, thanks!
now I just have to figure out how to either make a whole bunch of python/C behave from within pd, or jackify the lot...urgh.
my kingdom for Thomas's pyext signal stuff! (waiting patiently)
d
---
www.ariada.uea.ac.uk/~dcasal --)+
my kingdom for Thomas's pyext signal stuff! (waiting patiently)
This will require A LOT of patience since i don't even know about any plans of mine. On the other hand it would be nice to have some SndObj-like framework for Python. I'm sure that there's something like that out there... it would just need some interfacing....
best greetings, Thomas
On Wed, 30 Oct 2002, Thomas Grill wrote:
Hi Thomas, and all
This will require A LOT of patience since i don't even know about any plans of mine.
I was making reference (in a cheeky way) to something you said Oct 3rd:
grill wrote:
"The latter of course takes us to another level. If sample computation be realized in a Python external, how should the API look like? I haven't spent much of a thought on that but now i see the possibilities thank you for the pointer, David! For a general approach the Boodler interface style doesn't seem to be well fitted... it only supports 2 channels and 16 bits. I think i study the stuff a bit more and then try to implement a general signal interface for pyext (which could in a further step be specialized for the Boodler case)."
so I suppose the 'signal interface' is what I was talking about. Incidentally, I've now realised that trying to cope with onboard laptop sound when trying things like boodler+pd+whatever is too much, and that using something like the pcmcia hammerfall and assigning channels is far saner. Don't like throwing money at problems, but programming C for Jack is totally beyond me.
either way, I'm having too much fun with pyext as it is to complain!
just a' wishin', is all.
d
www.ariada.uea.ac.uk/~dcasal --)+
I'm on a Screamer so...
On Tue, 22 Oct 2002 10:11:08 +0100 (BST) david casal D.Casal@uea.ac.uk wrote:
Hi all,
Trying to to PD-->Jack. Ran into trouble:
I'm running Debian 2.4.18 on a powerbook (pismo G3). Got the CVS pd version of devel_0_35 and compiled with './configure --enable-jack --enable-alsa'.
Checked out Jack (CVS), tinkered with configure.in until autogen worked.
Have you tried jack_simple_client or somesuch to see if it would connect to the jack server?
tried to start jack with 'jackd -d alsa -d screamer', and it seemed fine:
you will probably want to start with 'jackd -d alsa -r 44100' bacause I don't think that Apple hardware supports 48000 sr. Also, try the default alsa device (the above command will choose automatically alsa's plugin layer, which jackd will complain about but it should work anyways).
loading driver .. creating alsa driver ... screamer|1024|2|48000|swmon starting engine
I've got a .asoundrc with:
pcm.screamer { type hw card 0 }
how about adding:
ctl.screamer { type hw card 0 }
.. but I'm no wizard...
pd -jack -verbose
PD's output:
Pd version 0.35 (MIDI stuff) using jack interface cannot read event connect result from server (No such device) cannot connect to server for event stream (No such device) (last 2 lines repeated 5 times) jack server not running?
Jack's output:
**** alsa_pcm: xrun of at least 4.253 msecs
unknown client ID in ACK connection request cannot complete client ACK connection process (last 2 lines repeated 5 times)
I have to run jackd and the jackified app under the same uid.
Thing is, I had quite a bit of trouble compiling ALSA for this powerbook, and I fear maybe the thing's gone mad...but I'm able to 'modprobe modprobe snd-powermac Any clues, anybody?
Did you try any other alsa audio application? ecasound? pd with alsa? to make sure that your alsa drivers are working correctly? Also, make sure that it's working full duplex on your machine (easy to check with these 2 apps).
Don't test with xmms because it's known to be deceitful with alsa on a PPC.
BTW, which version of ALSA? I had some problems with 0.9rc3 and I had to grab the CVS, but I think my problems were mostly MIDI related...
this isn't actually a direct reply to that message.. but reading it made me think of something. has anybody tried writing a VST instrument plugin interface for PD? it would be great to be able to run PD as a VSTi in cubase or something similar.... would this be really tough?
matt.
----- Original Message ----- From: "MLN Kazem, Aerospace Engineering" M.Kazem@bristol.ac.uk To: pd-list@iem.kug.ac.at Sent: Sunday, September 29, 2002 2:14 PM Subject: [PD] using other s/w with pd
Thanks Tom/Frank/Akira Abe for your replies,
firstly if I find any solution to life as we know it I promise I will let you know... My usage of pd is not music based so I'm sure I would be unwise to go down the VST plugin route, the other pieces of s/w that I want to use involve C/C++ APIs, interfaces implemented in a very similar way to those in the DirectSound API itself, interfaces which support COM objects - thus my highly windows restricted application (although it is promised that COM objects will be portable in the future???)... ... also my resources are limited....so I am trying (I suppose) to use functional C/C++ chunks of pd that I can insert into the controlling VC++ application. I don't require the GUI part of pd and therefore do not want pd to run as is, possibly I could use STK more easily in this fashion but pd seems to have more of what I require. It seems to me that through portaudio pd is creating the DirectSound COM objects, through the API, and once created surely I can use them?
Its Sunday and I am possibly more than a little confused....
thanks again - everything/ anything is a great help
ps how would using Linux help me get a license for ReWire? pps Jack is interesting, how do I get info on the linux interface? ppps am I on the wrong list?! (pd-list not pd-dev??)
Mandy
MLN Kazem, Aerospace Engineering M.Kazem@bristol.ac.uk Tel. 0117 9288219 Fax. 0117 9272771
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
I agree, that would be nice . . . . are there any plans !?
matthew nish-lapidus wrote:
this isn't actually a direct reply to that message.. but reading it made me think of something. has anybody tried writing a VST instrument plugin interface for PD? it would be great to be able to run PD as a VSTi in cubase or something similar.... would this be really tough?
matt.
----- Original Message ----- From: "MLN Kazem, Aerospace Engineering" M.Kazem@bristol.ac.uk To: pd-list@iem.kug.ac.at Sent: Sunday, September 29, 2002 2:14 PM Subject: [PD] using other s/w with pd
Thanks Tom/Frank/Akira Abe for your replies,
firstly if I find any solution to life as we know it I promise I will let you know... My usage of pd is not music based so I'm sure I would be unwise to go down the VST plugin route, the other pieces of s/w that I want to use involve C/C++ APIs, interfaces implemented in a very similar way to those in the DirectSound API itself, interfaces which support COM objects - thus my highly windows restricted application (although it is promised that COM objects will be portable in the future???)... ... also my resources are limited....so I am trying (I suppose) to use functional C/C++ chunks of pd that I can insert into the controlling VC++ application. I don't require the GUI part of pd and therefore do not want pd to run as is, possibly I could use STK more easily in this fashion but pd seems to have more of what I require. It seems to me that through portaudio pd is creating the DirectSound COM objects, through the API, and once created surely I can use them?
Its Sunday and I am possibly more than a little confused....
thanks again - everything/ anything is a great help
ps how would using Linux help me get a license for ReWire? pps Jack is interesting, how do I get info on the linux interface? ppps am I on the wrong list?! (pd-list not pd-dev??)
Mandy
MLN Kazem, Aerospace Engineering M.Kazem@bristol.ac.uk Tel. 0117 9288219 Fax. 0117 9272771
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list