[PD-dev] sms pd external - design choices

[Claude Heiland-Allen]

m_pd.h declares:

EXTERN t_pd *pd_findbyclass(t_symbol *s, t_class *c);

maybe that's worth investigating?

Rich E wrote:
> Hi all,
> 
> As I may have mentioned in a few other places, I have been working
> with a c library for analysis/synthesis known as SMS.  The library,
> although in flux still, is now capable for performing synthesis in
> real-time; I wrote a prototype external that does this by reading a
> streaming file from disk.
> 
> Now, I want to turn write a set of externals using a buffered
> analysis.  Originally, I thought that all operations to the buffer
> would happen using one external, but this now seems like it will get
> too messy once anything more than basic operations are attempted
> (something like cross-synthesis would take enough code to constitude
> its own external).  So, I have decided that, like the process of SMS,
> the different modes of operation should be seperated into analysis,
> synthesis, and editing.  However, they would all still need access to
> the same buffer (which could also be its own external, or possibly be
> inside the analysis external).
> 
> So now I am looking for a way to make it where various externals have
> access to the same buffer - a data structure containing a header and
> sequential frames of analysis.
> 
> I originally thought that outputting a pointer would be the easiest,
> but then realized that pd can output 'gpointers', which are not the
> same as a void pointer.  So it does not look possible to pass a
> regular c pointer around in pd land.
> 
> I see that [pool] has the ability to share a data space among
> different buffers by taking a name as its first argument.  I am
> digging through its code right now, but am not familiar with the flext
> API. I don't yet see how it manages to allow different [pool]'s to
> share the same data.
> 
> Any suggestions from this list is appreciated..
> 
> cheers,
> rich
> 
> On Jan 27, 2008 6:01 PM,  <geiger at xdv.org> wrote:
>> Quoting Rich E <reakinator at gmail.com>:
>>
>>> Hi Gunter Geiger, pd devs,
>>>
>>> I have recently begun to write an external for SMS synthesis, by basically
>>> porting the command line tool Xavier Serra wrote within the original SMS
>>> code (found at http://www.iua.upf.es/~sms/software/Old-SMS-for-NextStep.zip).
>>> I was talking to Xavier about this and he mentioned that you almost got an
>>> external working with sms.. Before I did too much work, I figured I would
>>> ask to see what types of problems you ran into, or if you have any
>>> suggestions.
>> Hi,
>>
>> I have part of the SMS process implemented, but not as a single external
>> but as a collection of externals for generation of windows, peak
>> detection, interpolation, FFT resynthesis. These are glued together
>> with standard
>> pd objects.
>> I sort of got stuck trying to figure out how to use the extracted data in
>> a meaningful way inside pd.
>>
>> So, after all,it might be a better approach to do it as a single external and
>> program your transformations in C/C++. So maybe the best bet would be
>> to have a
>> base SMS analysis/synthesis engine and do an external for each effect that
>> you want to implement with it.
>>
>> Gunter
>>
>>
>>
>>
>>
>>> I'm also sending this to the pd-dev list to see if others have suggestions.
>>> I figure that I will start by doing just a port of the command line tool,
>>> and then later add in features for seeking through frames at any speed and
>>> direction, visually manipulating the data, and other fun things.  But I
>>> would like to know what others think.
>>>
>>> regards,
>>> rich
>>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev