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, <[EMAIL PROTECTED]> wrote: >> Quoting Rich E <[EMAIL PROTECTED]>: >> >>> 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@iem.at > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev