On Dec 4, 2007, at 3:54 AM, IOhannes m zmoelnig wrote:
Russell Bryant wrote:
Hans-Christoph Steiner wrote:
Now that I think about it, it would also work to have each call open an instance of a patch within one constantly running Pd process.
just to make sure: you are not talking about creating a system that would do that for me as "the" way to use asterisk with Pd?
i think all it needs is an object that tells me that there is a new incoming connection and how to access it (that would basically just be an ID which can then be used to get the actual data; nevermind whether it is creating a new [streamin~] object, connecting to a new jack-port or just thawing a frozen part of the patch.
Then when the call is dropped, that patch instance would close. For this to work well, we'd need to add the ability for a patch to close itself programmatically (currently, when a patch sends menuclose to itself, Pd crashes :( )
just to re-iterate: i think you are planning on the wrong level. what you are planning seems to be a full-featured environment that does all kind of thinks for you. if i understood the problem correctly, we are not there yet; what,
imho, has to be done first is creating an as simple as possible way to
access the data from Pd. generative patches are most likely way to highlevel for this. once we have this low-level API, somebody could go and create the environment you are currently dreaming of.somebody else, could go and create an other environment, that fits
their needs better.Yes, that would certainly be the ideal way to do it. In fact,
instead of messing around with multiple Pd processes, I would much rather
just help solve whatever the problem is that causes this not to work.i agree that multiple Pd instances are not the way to go.
as i have said, i would keep it as simple as possible, and as
general as possible: my suggestion for asterisk is to use jack for dealing with the
audio lines. 2 ways come into my mind:
- open a new jack-port (in asterisk) for each call ; leave the
application to handle this (on the Pd side this is simple; one can redefine the audio-api (e.g. jack-ports used) at runtime; one would then need an external (most likely already written by kjetil) to do the jack-routing)
- start with a fixed number of jack-ports (maximum number of
simultaneous calls) in asterisk; pre-connect all jack-ports from asterisk to Pd and switch~ on/off patches for each line as they are opened/closed. i guess for many projects this super-simple approach
will be totally sufficient.both of these ideas seem to be simple to implement and have the
biggest overall advantage, not just for Pd, but _also_ for Pd, as they are far more simple to use than anything that does things automatically.
Just to be clear, I agree that the API shouldn't be stuck to a very
specific technique of working with instances of processes in Pd. I
just wanted to outline the possibilities and how they would work with
asterisk.
The current method of allocating the instances beforehand, then using
[switch] to turn them on and off does work. But for this thing to
scale to the kind of volumes that an asterisk box can handle, I think
the resources will need to be allocated dynamically. This is how
servers like apache handle it.
In order to make Pd do that, there is work that needs to be done,
specifically the stuff I mentioned about the DSP chain, and then
ability for a patch to close itself.
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams