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@xdv.org wrote:
Quoting Rich E reakinator@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.
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@xdv.org wrote:
Quoting Rich E reakinator@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@iem.at http://lists.puredata.info/listinfo/pd-dev
I should add that the library I have been working on, as well as lots of info on SMS can be found here: http://mtg.upf.edu/technologies/sms/
The prototype [smsSynthFile~] external is within the package close to the bottom of the file "libsms.tar.gz". To be warned, it crashes if things aren't done in the right order, which isn't well documented yet.
On Thu, Jul 10, 2008 at 10:35 AM, Rich E reakinator@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@xdv.org wrote:
Quoting Rich E reakinator@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.ziphttp://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.
Rich E wrote:
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.
If you have pd-extended or apply the string patch http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/packages/patches... , you can use t_blobs as a kind of atom:
typedef struct _blob /* pointer to a blob */ { unsigned long s_length; /* length of blob in bytes */ unsigned char *s_data; /* pointer to 1st byte of blob */ } t_blob;
It's totally up to you as The Programmer to keep track of the memory, Pd only passes the pointers around.
Martin
On Thu, 10 Jul 2008, Martin Peach wrote:
Rich E wrote:
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.
If you have pd-extended or apply the string patch http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/packages/patches... , you can use t_blobs as a kind of atom:
typedef struct _blob /* pointer to a blob */ { unsigned long s_length; /* length of blob in bytes */ unsigned char *s_data; /* pointer to 1st byte of blob */ } t_blob;
It's totally up to you as The Programmer to keep track of the memory, Pd only passes the pointers around.
It would be great to have people start using this string/blob functionality, but it needs to be changed so that it'll work without patching Pd itself. IOhannes outlined this idea, and we talked about it briefly in the past.
This current implementation of the string patch will need to be removed from the next release of Pd-extended (and should have been removed from this release).
The core of the idea that IOhannes mentioned is just declaring an external type number and using that, rather than patching Pd.
.hc
Martin
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
zen \ \ \[D[D[D[D
Hans-Christoph Steiner wrote:
It would be great to have people start using this string/blob functionality, but it needs to be changed so that it'll work without patching Pd itself. IOhannes outlined this idea, and we talked about it briefly in the past.
This current implementation of the string patch will need to be removed from the next release of Pd-extended (and should have been removed from this release).
The core of the idea that IOhannes mentioned is just declaring an external type number and using that, rather than patching Pd.
It sounds like a good idea but I really don't understand how it can work. I would code it but I don't know what to code :( It seems to me that if a type is unknown to Pd it will not be processed. Last time it took me about two weeks to get the string patch to work, and I don't seem to have that kind of time any more, so maybe IOhannes, who knows how to do it, could give it a go?
Martin
On Fri, 18 Jul 2008, Hans-Christoph Steiner wrote:
It would be great to have people start using this string/blob functionality, but it needs to be changed so that it'll work without patching Pd itself. IOhannes outlined this idea, and we talked about it briefly in the past.
How do you get [print] to print a peachy string?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Quoting Mathieu Bouchard matju@artengine.ca:
On Fri, 18 Jul 2008, Hans-Christoph Steiner wrote:
It would be great to have people start using this string/blob functionality, but it needs to be changed so that it'll work without patching Pd itself. IOhannes outlined this idea, and we talked about it briefly in the past.
How do you get [print] to print a peachy string?
in the way we (including miller) kind of agreed at LAC2008 the answer is simple: you don't.
my initial idea of having a "type registry" (which was turned down as it seemed to be too complicated for the "minor" (not so many devs would probably use it anyway) feature of adding more types) would have added a callback for the use in atom_getstring()
mfgasd,r# IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
zmoelnig@iem.at wrote:
Quoting Mathieu Bouchard matju@artengine.ca:
On Fri, 18 Jul 2008, Hans-Christoph Steiner wrote:
It would be great to have people start using this string/blob functionality, but it needs to be changed so that it'll work without patching Pd itself. IOhannes outlined this idea, and we talked about it briefly in the past.
How do you get [print] to print a peachy string?
in the way we (including miller) kind of agreed at LAC2008 the answer is simple: you don't.
my initial idea of having a "type registry" (which was turned down as it seemed to be too complicated for the "minor" (not so many devs would probably use it anyway) feature of adding more types) would have added a callback for the use in atom_getstring()
I'd be more worried about what to do when arbitrary atom-type-agnostic objects keep copies of my atoms around long after my world has deallocated the memory pointed to, and what to do when those expired atoms come back into my world...
Claude
On Sat, 19 Jul 2008, Claude Heiland-Allen wrote:
How do you get [print] to print a peachy string?
in the way we (including miller) kind of agreed at LAC2008 the answer is simple: you don't.
I'd be more worried about what to do when arbitrary atom-type-agnostic objects keep copies of my atoms around long after my world has deallocated the memory pointed to, and what to do when those expired atoms come back into my world...
Well, I'd be more worried about that too, but the thing is, I wanted to probe with a simple issue that has an obvious solution, and if everybody at LAC «kind of agreed» to Miller's not-giving-a-damn answer, nothing is going to be happening with a can-of-wormsish issue like memory allocation handling that potentially involves the interface to externals and all of the source code of all externals.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Claude Heiland-Allen wrote:
I'd be more worried about what to do when arbitrary atom-type-agnostic objects keep copies of my atoms around long after my world has deallocated the memory pointed to, and what to do when those expired atoms come back into my world...
well yes, this is something you (the developer using arbitrary types) has to worry about. i guess chances are low that something like a reference counter will make it into t_atom
fgmadsr IOhannes
On Sat, 19 Jul 2008, zmoelnig@iem.at wrote:
Quoting Mathieu Bouchard matju@artengine.ca:
How do you get [print] to print a peachy string?
in the way we (including miller) kind of agreed at LAC2008 the answer is simple: you don't.
Perhaps you don't, but I do print my A_LIST atoms right fucking now using an object called [print], in Miller's Pd, instead of agreeing with things that can either crash pd or make it do something undefined that has nothing to do with printing the contents of the string.
All this resignation must be bringing you closer to God...
my initial idea of having a "type registry" (which was turned down as it seemed to be too complicated for the "minor" (not so many devs would probably use it anyway) feature of adding more types) would have added a callback for the use in atom_getstring()
Yeah, well, I agree with your type registry idea, and I shall remember not to go to anything like LAC for the number of pd developers. It's a kind of reflex that I have to fight. I would have to go to LAC for any other interest. I believe that this general feeling of resignation is nothing less than nasty... it may end up killing pd as more hacks like that get piled up.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Sat, 19 Jul 2008, zmoelnig@iem.at wrote:
Quoting Mathieu Bouchard matju@artengine.ca:
How do you get [print] to print a peachy string?
in the way we (including miller) kind of agreed at LAC2008 the answer is simple: you don't.
Perhaps you don't, but I do print my A_LIST atoms right fucking now using an object called [print], in Miller's Pd, instead of agreeing with things that can either crash pd or make it do something undefined that has nothing to do with printing the contents of the string.
so how do you fookin' do it?
All this resignation must be bringing you closer to God...
yes.
Yeah, well, I agree with your type registry idea, and I shall remember not to go to anything like LAC for the number of pd developers. It's a kind of reflex that I have to fight. I would have to go to LAC for any
i think this is a good decision; if you do want to talk about Pd then you should go to Pd~con or ICMC or another computer-music oriented meeting. LAC used to be a lot about soundcard drivers and new tools/applications, none of which is a category Pd really falls into; i had the impression that a lot of old-school LACers where a bit overwhelmed (and probably frustrated) by the LAC2008 because of the focus on Pd (but then i was a bit frustrated by the focus on SC3 at LAC2007, esp. as many presentations were done on os-x with a remark "ah, this doesn't yet work on linux"); LAC2008 was still great (but i am not an ol-skool LACer)
mfga.sdr IOhannes
On Mon, 21 Jul 2008, IOhannes m zmoelnig wrote:
Perhaps you don't, but I do print my A_LIST atoms right now using an object called [print], in Miller's Pd
so how do you fookin' do it?
Well, I hinted at it in a kind of erratum because I wanted to say that I didn't patch pd. I forced [print] to be an alias of [gf.print], but first I wrote [gf.print], which is a C++-based clone of [print]... though I already had something similar because I had made [display].
i think this is a good decision; if you do want to talk about Pd then you should go to Pd~con
It's not like there's a Pd~con often enough. To me, Piksel 2005-2006 was an occasion to meet a good number of Pd people.
or ICMC or another computer-music oriented meeting.
Well, if I can find the same Pd people in both music-oriented and audio-oriented confs, there's not much difference.
LAC used to be a lot about soundcard drivers and new tools/applications, none of which is a category Pd really falls into; i had the impression that a lot of old-school LACers where a bit overwhelmed (and probably frustrated) by the LAC2008 because of the focus on Pd
So, why does it switch around from ... to SC3 to Pd to ...? and I suppose that at the same time it's not an official theme? Another conf trying to compensate for the lack of an annual Pd Convention?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
LAC used to be a lot about soundcard drivers and new tools/applications, none of which is a category Pd really falls into; i had the impression that a lot of old-school LACers where a bit overwhelmed (and probably frustrated) by the LAC2008 because of the focus on Pd
So, why does it switch around from ... to SC3 to Pd to ...?
People might get this impression because LAC2007 was co-organized by well-known SC3 users Stefan Kersten and Marije Baalman, while LAC2008 was co-organized by me.
But I think, this impression isn't correct: I attended every LAC since the first one. As Pd of course is one of the most important pieces of software in the Linux Audio community, it has played a major role in every LAC before (well, maybe not the first one).
This year we invited Miller for the keynote but ever other Pd user came without special invitation or financial support from LAC (We paid musicians a rather symbolic fee, but it was nothing compared to what you managed for pd~conv.)
Music and talks were selected by review boards, which consisted mostly of the same people as the year(s) before and which IMO wasn't biased, but instead had people from all major "camps" in it: experts for CSound, Pd, SC, ALSA, Jack, computer music in general etc.
But as Graz is close (flight-wise) to Cologne, IEM was there in full effect, and Hans had a talk at LAC, too, so organizing an informal meeting was only natural. Btw. I couldn't attend it neither.
Ciao
Am 10.07.2008 um 19:35 schrieb Rich E:
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.
Data sharing in pool is no flext-specific feature... you can do that with any external by making the shared data "static" (in c-style9, as opposed to be allocated with the object instances. gr~~~
I do not see how I could have more than one buffer at the same time if it were declared statically. The data has to be 'findable', so I need some way to name it. pd_findbyclass() seems to be the right tool for this, though I am still trying to figure out how to create the t_class that will have the sms data.
I think, after looking into the various possibilities, outputting a pointer to the data would just be confusing and might not work when sent through pd's messaging system. It appears that keeping the buffer by a symbol name would be cleaner.
On Fri, Jul 11, 2008 at 5:00 AM, Thomas Grill gr@grrrr.org wrote:
Data sharing in pool is no flext-specific feature... you can do that with
any external by making the shared data "static" (in c-style9, as opposed to be allocated with the object instances. gr~~~
How do you manage to keep multiple pool's then?
regards, Richie
Rich E wrote:
I do not see how I could have more than one buffer at the same time if it were declared statically. The data has to be 'findable', so I need some way to name it.
Well, you could do what Pd does, and have a static datastructure pointer, with a list/tree/whatever that you can look through to find values associated with keys. I think this is what the findbyclass stuff does internally, but you'd have to check the source to confirm and see how to use it (it's used in [value] and [table], and others too).
Claude
On Fri, Jul 11, 2008 at 5:00 AM, Thomas Grill gr@grrrr.org wrote:
Data sharing in pool is no flext-specific feature... you can do that with any external by making the shared data "static" (in c- style9, as opposed to be allocated with the object instances. gr~~~
How do you manage to keep multiple pool's then?
It's nothing but a c++ std::map, lookup up by the name symbol of the respective pool.
gr~~~
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@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@xdv.org wrote:
Quoting Rich E reakinator@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.ziphttp://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.
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Mathieu Bouchard -
Rich E -
Thomas Grill -
zmoelnig＠iem.at