[PD] Pd + asterisk?

Hans-Christoph Steiner hans at eds.org
Tue Dec 4 21:26:15 CET 2007




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






More information about the Pd-list mailing list