On Sat, Jun 16, 2012 at 5:01 PM, Matt Barber brbrofsvl@gmail.com wrote:
The user-settable bound would just be in how they decided to use it. Think of it like [until] -- there's no reason to make the user set an upper iteration bound - the user does that just by using it in a way that doesn't crash Pd (and some until loops are more expensive than others).
Maybe you're right. Though [tabwrite4~] would be more complicated to handle than [until], user-tests will indicate wether a 'safety belt' would be desired, it is not a prerequisite for the object's functioning.
The main thing I see wrong with what we've been calling "approach B" is that there isn't a good policy for what to do when 1) the index goes backwards in the table, and 2) what to do when the table already has info in it. One could have settable "interpolate on backwards jump" (default should probably be no) and settable "mix new samples with what's there, or overwrite them."
When the index goes backwards in the table, the object should write backwards, like [poke~] does. In my view, the object should always overwrite samples, like [poke~] again. I did my sound-on-sound looper with [poke~] and [tabread4~], a mix can be done externally. (see http://puredata.hurleur.com/sujet-5021-sound-sound-looper-clear-option).
Now, if we move forward, we need think about what to name it. [tabwrite~] currently does something that maybe should have been called [tabrecord~], so the [tabwrite4~] name is maybe a little misleading. The delay version could be called [vdw~] -- it would take two signals in and output one signal (there's no reason for it to maintain a multitap-able delay buffer because all the relevant work is done on the write end, so if you need multiple read taps you can just feed it into a [delwrite~] further down).
I like the name [tabwrite4~]. Every Pd user is (or will be) familiar with [tabwrite~] already, and [tabwrite4~] will be used in combination with [tabread4~], nothing could be more logical.
For various reasons I think what we've been calling approach A -- writing a filter kernel into the buffer for every sample is better for the delay version than approach B, but I can't get into it right now as I'm about to board a plane!
Matt
I'm about to leave for a 3 week holiday, computers will stay home! (I'm almost tempted to smuggle one in my luggage and write the class in my tent, Pd addict I am).
Katja
On Sat, Jun 16, 2012 at 12:03 PM, katja katjavetter@gmail.com wrote:
On Sat, Jun 16, 2012 at 5:01 PM, Matt Barber brbrofsvl@gmail.com wrote:
The user-settable bound would just be in how they decided to use it. Think of it like [until] -- there's no reason to make the user set an upper iteration bound - the user does that just by using it in a way that doesn't crash Pd (and some until loops are more expensive than others).
Maybe you're right. Though [tabwrite4~] would be more complicated to handle than [until], user-tests will indicate wether a 'safety belt' would be desired, it is not a prerequisite for the object's functioning.
The main thing I see wrong with what we've been calling "approach B" is that there isn't a good policy for what to do when 1) the index goes backwards in the table, and 2) what to do when the table already has info in it. One could have settable "interpolate on backwards jump" (default should probably be no) and settable "mix new samples with what's there, or overwrite them."
When the index goes backwards in the table, the object should write backwards, like [poke~] does. In my view, the object should always overwrite samples, like [poke~] again. I did my sound-on-sound looper with [poke~] and [tabread4~], a mix can be done externally. (see http://puredata.hurleur.com/sujet-5021-sound-sound-looper-clear-option).
Consider the use case where one wants to use the table as a buffer and they write through it and loop back to the beginning of the table when it reaches the end. Let's say the table is 44100 samples long, and the index loops from 44087.3 to 2.1 to start writing the table again. Does it interpolate all the intervening samples BACK through the table, or does it interpolate the 14 or so samples FORWARD through the loop? Or neither? These are all possibilities.
As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source).
Note that "approach A" depends on mixing to work because the interpolation would need to be the emergent result of having mixed kernels into the table. "Overwriting" would defeat the purpose entirely.
Now, if we move forward, we need think about what to name it. [tabwrite~] currently does something that maybe should have been called [tabrecord~], so the [tabwrite4~] name is maybe a little misleading. The delay version could be called [vdw~] -- it would take two signals in and output one signal (there's no reason for it to maintain a multitap-able delay buffer because all the relevant work is done on the write end, so if you need multiple read taps you can just feed it into a [delwrite~] further down).
I like the name [tabwrite4~]. Every Pd user is (or will be) familiar with [tabwrite~] already, and [tabwrite4~] will be used in combination with [tabread4~], nothing could be more logical.
I think I agree -- the only problem is that we have different analogies.
Consider all of the following:
[tabread] : [tabread4] (control, with or without interpolation) [tabread4] : [tabread4~] (interpolating, one control and one for signals) [tabwrite] : [poke~] (write at an index using control or signal) [tabwrite~] : [tabplay~] (record a signal to a table, or play a signal from a table) [tabread4~] : [tabwrite4~] (read or write samples at specific index from/to a table with interpolation) [tabwrite~] : [tabwrite4~] (write samples to a table at specific index to a table, with or without interpolation) -- wait, that's not what tabwrite~ does! [tabwrite~] could have been maybe better named [tabrecord~]. [tabwrite] and [poke~] are the analogous objects, so one could make a case for calling it [poke4~] (does the same thing as [poke~] but with interpolation, in the Pd nomenclature).
Or maybe [tabwrite4~] would imply to some people that you don't control it with indices, but with an up- or downsampling factor.
I think [tabwrite4~] is the best name for what we've been talking about, but the asymmetry with the names of other objects gives me pause.
OK, onto the next flight!
On Sat, Jun 16, 2012 at 7:16 PM, Matt Barber brbrofsvl@gmail.com wrote:
When the index goes backwards in the table, the object should write backwards, like [poke~] does. In my view, the object should always overwrite samples, like [poke~] again. I did my sound-on-sound looper with [poke~] and [tabread4~], a mix can be done externally. (see http://puredata.hurleur.com/sujet-5021-sound-sound-looper-clear-option).
Consider the use case where one wants to use the table as a buffer and they write through it and loop back to the beginning of the table when it reaches the end. Let's say the table is 44100 samples long, and the index loops from 44087.3 to 2.1 to start writing the table again. Does it interpolate all the intervening samples BACK through the table, or does it interpolate the 14 or so samples FORWARD through the loop? Or neither? These are all possibilities.
You're right, there should be a user-settable loop size (which is not by necessity identical to table size) and if the forward or backward interval is equal or larger than loop size, a wrap is done. But wait: if the check is done anyway, it could as well be (a)bused to set an upper bound to upsampling....
As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source).
But 'approach B' condenses 4 read samples into 1 write sample, so basically it does the same as [poke]: writing one sample at a time. There is no need for mixing internally. If you want to mix, it can be done externally. In my view, a Pd object need not internalize functions that can be done externally, unless there is a huge performance penalty involved.
Note that "approach A" depends on mixing to work because the interpolation would need to be the emergent result of having mixed kernels into the table. "Overwriting" would defeat the purpose entirely.
Yes, with 'approach A' mixing is essential, as the tails of the kernels must overlap. Then you get the amplitude effect. It is a completely different model, and maybe these models each have their own field of application.
I like the name [tabwrite4~]. Every Pd user is (or will be) familiar with [tabwrite~] already, and [tabwrite4~] will be used in combination with [tabread4~], nothing could be more logical.
I think I agree -- the only problem is that we have different analogies.
Consider all of the following:
[tabread] : [tabread4] (control, with or without interpolation) [tabread4] : [tabread4~] (interpolating, one control and one for signals) [tabwrite] : [poke~] (write at an index using control or signal) [tabwrite~] : [tabplay~] (record a signal to a table, or play a signal from a table) [tabread4~] : [tabwrite4~] (read or write samples at specific index from/to a table with interpolation) [tabwrite~] : [tabwrite4~] (write samples to a table at specific index to a table, with or without interpolation) -- wait, that's not what tabwrite~ does! [tabwrite~] could have been maybe better named [tabrecord~]. [tabwrite] and [poke~] are the analogous objects, so one could make a case for calling it [poke4~] (does the same thing as [poke~] but with interpolation, in the Pd nomenclature).
Or maybe [tabwrite4~] would imply to some people that you don't control it with indices, but with an up- or downsampling factor.
I think [tabwrite4~] is the best name for what we've been talking about, but the asymmetry with the names of other objects gives me pause.
Yeah [poke4~] is apt for a 4 point interpolating signal write object with index control.
OK, onto the next flight!
Have a good trip!
Katja
As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source).
But 'approach B' condenses 4 read samples into 1 write sample, so basically it does the same as [poke]: writing one sample at a time. There is no need for mixing internally. If you want to mix, it can be done externally. In my view, a Pd object need not internalize functions that can be done externally, unless there is a huge performance penalty involved.
Here is one use case where mixing as part of the function would be useful. Imagine you're trying to model a sound source moving at mach+ speeds -- let's say it starts 500 meters away from the microphone and plays for 3 seconds, and then it moves toward the microphone at twice the speed of sound until it gets two meters away, and then (against any sensible law of inertia) it turns on a dime and moves away from the mic again at .25 the speed of sound.
Much of the sound it generates after it makes the turn will reach the microphone before the sound it was making when it started its approach toward the microphone reaches the mic (since the source overtakes its own previous sound).
Moving toward the mic faster than sound is analogous to moving backwards in the table, and for it to be correct it needs to mix rather than overwrite, and it would be very difficult to maintain separate copies of everything and mix it elsewhere in Pd for anything where the control signal is less predictable.
So, maybe this is a totally exceptional case that isn't worth caring about, but I'd like to note that this kind of thing (not necessarily faster-than-speed sound, but the physical model) is exactly the motivation for the movable write into a delay line used in room simulation and/or distance encoding in ambisonics, and I think there ought to be at least a switch at the end of the creation argument line that only interested people would use and everyone else can forget about (that is, if "approach B" turns out to work well in the first place).
Matt
On 17/06/12 12:37, Matt Barber wrote:
As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source).
But 'approach B' condenses 4 read samples into 1 write sample, so basically it does the same as [poke]: writing one sample at a time. There is no need for mixing internally. If you want to mix, it can be done externally. In my view, a Pd object need not internalize functions that can be done externally, unless there is a huge performance penalty involved.
Here is one use case where mixing as part of the function would be useful. Imagine you're trying to model a sound source moving at mach+ speeds -- let's say it starts 500 meters away from the microphone and plays for 3 seconds, and then it moves toward the microphone at twice the speed of sound until it gets two meters away, and then (against any sensible law of inertia) it turns on a dime and moves away from the mic again at .25 the speed of sound.
Much of the sound it generates after it makes the turn will reach the microphone before the sound it was making when it started its approach toward the microphone reaches the mic (since the source overtakes its own previous sound).
Not so sure that mixing makes sense in this example if you are trying to model something physical ... something moving that fast (for your example a bullet which is shot out of a rifle then bounces back off something very substantial and hard to produce the trajectory you described) would create a sonic boom (a conical wave front) rather than a sound reversed in time while it was travelling supersonically. You get a kind of 3D bow-wave produced, like a boat in water, rather than neat sound ripples following slowly along behind the source in some kind of overlapping spherical wave front pattern. So you would not want to mix, but rather would need to model the boom followed by the sound produced after the slowdown. I don't know how one would model the sound behind/inside the cone while the object was still travelling supersonically, but might guess it was turbulent and noisy, probably something a bit like the wake of a boat. Also not sure what model you would use to deal with sound produced just before the fast travel, but where the projectile caught up and the sonic boom disrupted the nice spherical wave fronts.
But you might want to do a mix for other reasons.
Simon
On Sun, Jun 17, 2012 at 1:34 AM, Simon Wise simonzwise@gmail.com wrote:
On 17/06/12 12:37, Matt Barber wrote:
As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it wouldn't be useful to model a moving sound source).
But 'approach B' condenses 4 read samples into 1 write sample, so basically it does the same as [poke]: writing one sample at a time. There is no need for mixing internally. If you want to mix, it can be done externally. In my view, a Pd object need not internalize functions that can be done externally, unless there is a huge performance penalty involved.
Here is one use case where mixing as part of the function would be useful. Imagine you're trying to model a sound source moving at mach+ speeds -- let's say it starts 500 meters away from the microphone and plays for 3 seconds, and then it moves toward the microphone at twice the speed of sound until it gets two meters away, and then (against any sensible law of inertia) it turns on a dime and moves away from the mic again at .25 the speed of sound.
Much of the sound it generates after it makes the turn will reach the microphone before the sound it was making when it started its approach toward the microphone reaches the mic (since the source overtakes its own previous sound).
Not so sure that mixing makes sense in this example if you are trying to model something physical ... something moving that fast (for your example a bullet which is shot out of a rifle then bounces back off something very substantial and hard to produce the trajectory you described) would create a sonic boom (a conical wave front) rather than a sound reversed in time while it was travelling supersonically. You get a kind of 3D bow-wave produced, like a boat in water, rather than neat sound ripples following slowly along behind the source in some kind of overlapping spherical wave front pattern. So you would not want to mix, but rather would need to model the boom followed by the sound produced after the slowdown. I don't know how one would model the sound behind/inside the cone while the object was still travelling supersonically, but might guess it was turbulent and noisy, probably something a bit like the wake of a boat. Also not sure what model you would use to deal with sound produced just before the fast travel, but where the projectile caught up and the sonic boom disrupted the nice spherical wave fronts.
But you might want to do a mix for other reasons.
Yes, good points, and thanks. But it does make a fun "what if" -- I guess my scenario is more literally like a write head moving toward a read head faster than the speed of the tape. You're right that it's an utterly different medium than air.
Matt
What does Csound's vdelayxw do: mix or overwrite?
-Jonathan
----- Original Message -----
From: Matt Barber brbrofsvl@gmail.com To: katja katjavetter@gmail.com Cc: pd-list pd-list@iem.at Sent: Sunday, June 17, 2012 12:37 AM Subject: Re: [PD] ipoke~ ?
As far as mixing vs. overwriting is concerned, that actually depends on what it's trying to model. Overwriting is probably right for a looper, but mixing is right for a recording of a moving sound source - and because [poke~] doesn't interpolate it's not an issue (it
wouldn't
be useful to model a moving sound source).
But 'approach B' condenses 4 read samples into 1 write sample, so basically it does the same as [poke]: writing one sample at a time. There is no need for mixing internally. If you want to mix, it can be done externally. In my view, a Pd object need not internalize functions that can be done externally, unless there is a huge performance penalty involved.
Here is one use case where mixing as part of the function would be useful. Imagine you're trying to model a sound source moving at mach+ speeds -- let's say it starts 500 meters away from the microphone and plays for 3 seconds, and then it moves toward the microphone at twice the speed of sound until it gets two meters away, and then (against any sensible law of inertia) it turns on a dime and moves away from the mic again at .25 the speed of sound.
Much of the sound it generates after it makes the turn will reach the microphone before the sound it was making when it started its approach toward the microphone reaches the mic (since the source overtakes its own previous sound).
Moving toward the mic faster than sound is analogous to moving backwards in the table, and for it to be correct it needs to mix rather than overwrite, and it would be very difficult to maintain separate copies of everything and mix it elsewhere in Pd for anything where the control signal is less predictable.
So, maybe this is a totally exceptional case that isn't worth caring about, but I'd like to note that this kind of thing (not necessarily faster-than-speed sound, but the physical model) is exactly the motivation for the movable write into a delay line used in room simulation and/or distance encoding in ambisonics, and I think there ought to be at least a switch at the end of the creation argument line that only interested people would use and everyone else can forget about (that is, if "approach B" turns out to work well in the first place).
Matt
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, Jun 17, 2012 at 3:16 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
What does Csound's vdelayxw do: mix or overwrite?
It's based on "approach A" -- mixing a kernel into the buffer, so it mixes automatically. The read head of the delay line zeroes each sample out after reading.
Matt
----- Original Message -----
From: Matt Barber brbrofsvl@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: katja katjavetter@gmail.com; pd-list pd-list@iem.at Sent: Sunday, June 17, 2012 10:48 AM Subject: Re: [PD] ipoke~ ?
On Sun, Jun 17, 2012 at 3:16 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
What does Csound's vdelayxw do: mix or overwrite?
It's based on "approach A" -- mixing a kernel into the buffer, so it mixes automatically. The read head of the delay line zeroes each sample out after reading.
Then what is achieved by the approach of writing directly to a table that cannot be achieved by taking the output from the read head and [tabwrite~]ing it into a table? You can set the window size with [block~], no?
Hopefully that makes sense-- I'm still not completely sure on the difference between the two approaches.
-Jonathan
Matt
Apologies for the delay in responding, I'm also away atm.
Katja & Matt (and anyone else) - we should contact P.A. and get this moving. It may be best if we formulate an email between us to get the source code, rather than us all contacting him separately, and take it from there. I'm more than happy to keep this on-list (unless it pisses people off) in the spirit of open communication. Perhaps we should fork the topic though?
Really good that people are up for this, makes me happy.
Cheers,
Julian
P.S. Something been bugging me about my previous email. I really don't want to in any way denigrate the work that H.C. puts into PdE. What I meant by P.A. only being into vanilla is the robustness and cross platform nature of vanilla and that some of the objects in Extended work on some os's and not others. Or something. Hmmm, perhaps I should just stop digging in this particular hole.
Let's not forget that P.A.'s also hardcore Max/MSP so, you know, I've had nearly 3 years of him trying to get a rise out of me about all of this. No question though that he's slowly moving over to our direction these days.
I didn't expect to open such a large thread...just wanted to know whether it was any object to perform injection into a delay line. Two (complementary) possibilities: insert at arbitrary time points with fractional delay deinterpolation techniques (pretty easy to implement manually anyway, I can do this way by now), and being able to write into a delay line at different "speeds", that is, sub/oversampling, by moving a pointer at a speed different than 1sample/1sample period. This looks rather harder... Josep M
Date: Tue, 19 Jun 2012 18:15:25 +0100 From: jbeezez@gmail.com To: katjavetter@gmail.com CC: pd-list@iem.at Subject: Re: [PD] ipoke~ ?
Apologies for the delay in responding, I'm also away atm.
Katja & Matt (and anyone else) - we should contact P.A. and get this moving. It may be best if we formulate an email between us to get the source code, rather than us all contacting him separately, and take it from there. I'm more than happy to keep this on-list (unless it pisses people off) in the spirit of open communication. Perhaps we should fork the topic though?
Really good that people are up for this, makes me happy.
Cheers,
Julian
P.S. Something been bugging me about my previous email. I really don't want to in any way denigrate the work that H.C. puts into PdE. What I meant by P.A. only being into vanilla is the robustness and cross platform nature of vanilla and that some of the objects in Extended work on some os's and not others. Or something. Hmmm, perhaps I should just stop digging in this particular hole.
Let's not forget that P.A.'s also hardcore Max/MSP so, you know, I've had nearly 3 years of him trying to get a rise out of me about all of this. No question though that he's slowly moving over to our direction these days.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Joseph,
I'm back and rereading the thread to attempt to get a grip on this.
Just wanted to say that I hope you don't mind that your initial post has exploded into something else - you triggered a good one though, well done.
I would be delighted to have a peek at your solution to this (admittedly slightly different) problem as I'm sure it would help my own limited knowledge of these complex issues to see something in action, if you wouldn't mind sharing?
All good wishes,
Julian
Hey all,
So, after re-reading the thread I guess we're at the point where some [iPoke~] source would be helpful.
It would seem that there is still two possible approaches for the [tabwrite4~] option (A & B), plus some still to be resolved issues such as mixing/overwriting which presumably could be user-settings/options dependent on the proposed usage e.g. modelling a moving source vs looping software which are two very different practical issues. Right? I would certainly be in favour, if it makes communal sense, to have one object which could do both and, as of yet, other unforeseen things.
Perhaps too a reasonably straight port of [iPoke]? would be a good first project to get this moving towards the proposed [tabwrite4~] or is part of the problem that currently within Pd [iPoke~] is just not doable?
BTW, my 2-penneth, etc etc - naming wise, if we have hit upon something which appears to be a fundamental lack from within current Pd I have to admit to having a slight reservation on encroaching upon Miller's naming strategy, i.e. would we be bagging something which he would prefer to keep open for himself? It is a damn good name.
Below is a first draft to P.A., please amend/contribute/re-write/leave as you see fit:
Dear P.A.,
Thank you for the kind offer to make the source code of your Max/MSP external [iPoke~] available for a port to Pd.
The source code will be shared amongst a small group of interested and able Pd coders who have been contributing to a discussion on the Pd-list ('[PD] ipoke~?') working towards a proposed new object (current working title [tabwrite4~]). Porting [iPoke~] and being able to understand how you have managed to resolve some of the issues we currently face (with all due credit), would be fundamental towards attempting to solve this very interesting conundrum.
Currently we have not discussed some of the various important practical issues such as licensing and who and where this new object would be maintained.
Our first aim would be to create a robust and cross-platform [iPoke~] which would submit to all of our high standards.
It has been suggested that in keeping with a strategy of clear and open communication we keep this discussion 'on-list' so please feel free to respond in kind, or not.
Very best wishes and look forward to hearing from you soon.
Julian, it is a good idea to first ask P.A. to share the code among a small group and discuss licence, naming and maintainance matters. I am still not back home (this mail is typed from a tourist office), but in one week I will be ready to join in fully.
cheers, Katja
On 6/28/12, Julian Brooks jbeezez@gmail.com wrote:
Hey all,
So, after re-reading the thread I guess we're at the point where some [iPoke~] source would be helpful.
It would seem that there is still two possible approaches for the [tabwrite4~] option (A & B), plus some still to be resolved issues such as mixing/overwriting which presumably could be user-settings/options dependent on the proposed usage e.g. modelling a moving source vs looping software which are two very different practical issues. Right? I would certainly be in favour, if it makes communal sense, to have one object which could do both and, as of yet, other unforeseen things.
Perhaps too a reasonably straight port of [iPoke]? would be a good first project to get this moving towards the proposed [tabwrite4~] or is part of the problem that currently within Pd [iPoke~] is just not doable?
BTW, my 2-penneth, etc etc - naming wise, if we have hit upon something which appears to be a fundamental lack from within current Pd I have to admit to having a slight reservation on encroaching upon Miller's naming strategy, i.e. would we be bagging something which he would prefer to keep open for himself? It is a damn good name.
Below is a first draft to P.A., please amend/contribute/re-write/leave as you see fit:
Dear P.A.,
Thank you for the kind offer to make the source code of your Max/MSP external [iPoke~] available for a port to Pd.
The source code will be shared amongst a small group of interested and able Pd coders who have been contributing to a discussion on the Pd-list ('[PD] ipoke~?') working towards a proposed new object (current working title [tabwrite4~]). Porting [iPoke~] and being able to understand how you have managed to resolve some of the issues we currently face (with all due credit), would be fundamental towards attempting to solve this very interesting conundrum.
Currently we have not discussed some of the various important practical issues such as licensing and who and where this new object would be maintained.
Our first aim would be to create a robust and cross-platform [iPoke~] which would submit to all of our high standards.
It has been suggested that in keeping with a strategy of clear and open communication we keep this discussion 'on-list' so please feel free to respond in kind, or not.
Very best wishes and look forward to hearing from you soon.
Dear P.A.,
Thank you for the kind offer to make the source code of your Max/MSP external [iPoke~] available for a port to Pd.
The source code will be shared amongst a small group of interested and able Pd coders who have been contributing to the discussion on the Pd-list ('[PD] ipoke~?') working towards a proposed new object (current working title [tabwrite4~]). Porting [iPoke~] and being able to understand how you have managed to resolve some of the issues we currently face (with all due credit), would be fundamental towards attempting to solve this very interesting conundrum.
Currently we have not discussed some of the various important practical issues such as licensing and where and by whom this new object would be maintained. Obviously this is something that can only be resolved with your (and presumably Alex's) input.
Our first aim would be to create a robust and cross-platform [iPoke~] which would submit to all of our high standards.
It has been suggested that in keeping with a strategy of clear and open communication we keep this discussion 'on-list' so please feel free to respond in kind, or not.
Very best wishes and looking forward to hearing from you soon.
Hey all,
Spoke to P.A. who has asked for any interested party to contact him directly for the source code.
p.a.tremblay@hud.ac.uk
Cheers,
Julian
Thanks for your mediation Julian. Pierre Alexandre sent ipoke~.c to Charles and to me. If anyone else interested in collaboration on a Pd port please join in. P.A. plans to release ipoke~ under BSD-ish license. Hopefully he'll do that soon so we can discuss details on list, share test versions etc.
Katja
On Mon, Jul 16, 2012 at 1:26 PM, Julian Brooks jbeezez@gmail.com wrote:
Hey all,
Spoke to P.A. who has asked for any interested party to contact him directly for the source code.
p.a.tremblay@hud.ac.uk
Cheers,
Julian
Yep, count me in. I'm going to be out for a week but will have email access on my phone.
A couple of years ago there was a big discussion about different cubic interpolators, and some of us put together classes and did some benchmarking on the different approaches. I'm not sure how [ipoke~] does what it does, but I'd want to leave the idea of several approaches open (maybe along the lines outlined in this thread) to see what will work best for Pd.
Matt
On Tue, Jun 19, 2012 at 1:15 PM, Julian Brooks jbeezez@gmail.com wrote:
Apologies for the delay in responding, I'm also away atm.
Katja & Matt (and anyone else) - we should contact P.A. and get this moving. It may be best if we formulate an email between us to get the source code, rather than us all contacting him separately, and take it from there. I'm more than happy to keep this on-list (unless it pisses people off) in the spirit of open communication. Perhaps we should fork the topic though?
Really good that people are up for this, makes me happy.
Cheers,
Julian
P.S. Something been bugging me about my previous email. I really don't want to in any way denigrate the work that H.C. puts into PdE. What I meant by P.A. only being into vanilla is the robustness and cross platform nature of vanilla and that some of the objects in Extended work on some os's and not others. Or something. Hmmm, perhaps I should just stop digging in this particular hole.
Let's not forget that P.A.'s also hardcore Max/MSP so, you know, I've had nearly 3 years of him trying to get a rise out of me about all of this. No question though that he's slowly moving over to our direction these days.
Hey Matt,
Excellent news. A flexible approach sounds right too. You know, as a non-Max'er I actually have never seen iPoke~ in action! I know more about it through this thread than anything else.
Anyways, good stuff.
Regards,
J.
On Thu, Jun 21, 2012 at 9:28 AM, Matt Barber brbrofsvl@gmail.com wrote:
I'm not sure how [ipoke~] does what it does, but I'd want to leave the idea of several approaches open (maybe along the lines outlined in this thread) to see what will work best for Pd.
Matt
One thing to consider is the possibility of a one-sided (non-symmetric) function instead of a strict interpolator. Using a symmetric interpolator adds some latency--to band-limit the incoming signal with a symmetric interpolator, your samples need to extend into the future.
Now, if you take a non-symmetric function, what's the worst that happens? You get up to pi/4 radians of phase shift in the passband and up to pi/2 radians in the stopband. It jworks more like a band-limited estimator than an interpolator.
If you condition the input signal well, then filling the table consecutively might work and be fast.
Chuck
-
Charles Henry -
Jeppi Jeppi -
Jonathan Wilkes -
Julian Brooks -
katja -
Matt Barber -
Simon Wise