[PD-dev] sms pd external - design choices

[Rich E]

For better or for worse, I implemented the buffer system using
pd_findbyclass() and the key/value pair idea.  It works as long as all the
externals are coded in the same file (there has to be a way to declare the
data structure extern so it can be used by multiple files, but my knowledge
of programming fails me here), which I'm just accepting for now.

I have an analysis external working, called [smsanal], that will analyze an
audio file or pd array of samples.  The problem is that it causes quite a
large crunch, since the analysis is all happening in one while loop.  I'm
wondering how others would avoid something like this and space out the
analysis.  I am considering doing the analysis in the dsp loop and just
limiting the analysis until it is unnoticeable, but this has drawbacks.  For
one, it could make audio samples drop when other things start to get heavy.
Two, dsp would always have to be on.

[readsf~] opens its own thread, but it looked a little complicated to me...
and don't know too much about this side of programming.  Anyone else have a
suggestion?

So far you guys have helped me quite a bit in making good decisions in this
project... and I should have something to release soon.

Thanks again in advance,
Rich

On Thu, Jul 10, 2008 at 10:35 AM, Rich E <reakinator at gmail.com> 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<http://www.iua.upf.es/%7Esms/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.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20080825/e2bc9dc1/attachment.htm>