hello,
i'm still trying to understand why pd sound quality is not very good.
i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal. so, i just made few objects to replaced them (most of the code are copy from pd sources), but using a true 4 points cubic interpolation. i personally consider this to sound better than the pd version (specially with small tables), and they did not use more cpu.
this objects (located in svn/externals/nusmuk/tab/) are just for test, but they can fully replace the standard tabosc4~ and tabread4~.
i think higher order interpolation can be useful for even better audio quality, but i'm wondering if someone already worked on this. if not, i'll like to make a few tabread equivalent with diferents interpolation schematics (when i'll have more time...).
cyrille
On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal.
Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad?
Chuck
Charles Henry a écrit :
On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal.
Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad?
well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation.
i program a cubic interpolation, and the shape of the waveform is really different.
please compile the object and look at the help patch to see the difference.
i can also send waveforme picture if needed.
cyrille
Chuck
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I believe "lagrange interpolation" just means polynomail. tabread4~ uses cubic interpolation... details are in http://crca.ucsd.edu/~msp/techniques/latest/book-html/node31.html
It may be that there's a better way to do 4-point interpoation than Lagrange but the way to find out would be by doing careful distortion measurements. In particular, I know there are ways do do 4-point interpolation that don't give discontinuous first derivatives, but I think most measures of distortion would indicate using the Lagrance one instead.
cheers Miller
On Tue, Jun 10, 2008 at 05:29:49PM +0200, cyrille henry wrote:
Charles Henry a ?crit :
On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal.
Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad?
well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation.
i program a cubic interpolation, and the shape of the waveform is really different.
please compile the object and look at the help patch to see the difference.
i can also send waveforme picture if needed.
cyrille
Chuck
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
ok, thanks for the answer. i understand what's in your book, but i found other references where cubic interpolation is used for a function that offer continuity of the 1st derivative.
i can understand that tabread4~ minimise the error when the table is large (when you play it faster than the original speed). but with a small table, or when you play it slower, the first derivative discontinuity create lot's of high frequency.
So, in this condition, the function i use offer a better quality. see in the svn externals/nusmuk/tab/tabosc4c~-help.pd for more.
cyrille
Miller Puckette a écrit :
I believe "lagrange interpolation" just means polynomail. tabread4~ uses cubic interpolation... details are in http://crca.ucsd.edu/~msp/techniques/latest/book-html/node31.html
It may be that there's a better way to do 4-point interpoation than Lagrange but the way to find out would be by doing careful distortion measurements. In particular, I know there are ways do do 4-point interpolation that don't give discontinuous first derivatives, but I think most measures of distortion would indicate using the Lagrance one instead.
cheers Miller
On Tue, Jun 10, 2008 at 05:29:49PM +0200, cyrille henry wrote:
Charles Henry a ?crit :
On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal.
Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad?
well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation.
i program a cubic interpolation, and the shape of the waveform is really different.
please compile the object and look at the help patch to see the difference.
i can also send waveforme picture if needed.
cyrille
Chuck
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2008-06-11 at 00:05 +0200, cyrille henry wrote:
i can understand that tabread4~ minimise the error when the table is large (when you play it faster than the original speed). but with a small table, or when you play it slower, the first derivative discontinuity create lot's of high frequency.
hm... several times i had the impression, i used [tabread~] instead of [tabread4~] because of the high frequencies, that are audible, even if the sample is played very slowly. i assume, those come from the discontinuites you mentioned. but when i compared to [tabread~], there was definitely a huge difference. however, just out of curiosity, i wonder, whether a different algorithm is optimal for playing faster than original than for playing slower.
i am looking forward to check your classes.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
I'm really looking forward to giving this the 'ear test'.
Maybe I'm growing old but differerences in interpolation methods are very subtle to my perception. What would be the hard case to test it? It would be when the signal is greatly transposed, right?
Remember when I tested your stab at sinc interpolation Charles, I honestly couldn't hear an big difference, there was one, but hard to define.
Andy
ok, if you don't wish to compile in order to test, here are 2 samples :
http://www.chdh.free.fr/tab/tabosc4.wav http://www.chdh.free.fr/tab/tabosc4c.wav
note that this is the worst case for tabread4~ : a very small table play at low frequency.
for bigger table, the difference can be very small. here is a picture of the patch used to make this samples : http://www.chdh.free.fr/tab/patch.jpg
cyrille
Andy Farnell a écrit :
I'm really looking forward to giving this the 'ear test'.
Maybe I'm growing old but differerences in interpolation methods are very subtle to my perception. What would be the hard case to test it? It would be when the signal is greatly transposed, right?
Remember when I tested your stab at sinc interpolation Charles, I honestly couldn't hear an big difference, there was one, but hard to define.
Andy
I'm interested in this too... I'm deep inside something else right now but will check this out when I can.
cheers M
On Wed, Jun 11, 2008 at 02:23:11PM +0200, cyrille henry wrote:
ok, if you don't wish to compile in order to test, here are 2 samples :
http://www.chdh.free.fr/tab/tabosc4.wav http://www.chdh.free.fr/tab/tabosc4c.wav
note that this is the worst case for tabread4~ : a very small table play at low frequency.
for bigger table, the difference can be very small. here is a picture of the patch used to make this samples : http://www.chdh.free.fr/tab/patch.jpg
cyrille
Andy Farnell a ?crit :
I'm really looking forward to giving this the 'ear test'.
Maybe I'm growing old but differerences in interpolation methods are very subtle to my perception. What would be the hard case to test it? It would be when the signal is greatly transposed, right?
Remember when I tested your stab at sinc interpolation Charles, I honestly couldn't hear an big difference, there was one, but hard to define.
Andy
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 11 Jun 2008, cyrille henry wrote:
ok, if you don't wish to compile in order to test, here are 2 samples : http://www.chdh.free.fr/tab/tabosc4.wav http://www.chdh.free.fr/tab/tabosc4c.wav note that this is the worst case for tabread4~ : a very small table play at low frequency.
I believe that the difference will be more perceivable in non-sound contexts or at least non-waveform contexts, e.g. video/OpenGL, or sequencing.
for bigger table, the difference can be very small.
For a normal 4-point interpolator, the size of the table does not matter, because you always only use the previous two points and the next two points. It's just the scale at which you are looking at the thing, that gives the impression of large details.
I tried [tabread4] between two arrays of different sizes, to visualise interpolation, and just clicking around in one array for a few minutes got me to produce quite wild discontinuities of first derivative. This has little to do with the twice-continuously-differentiable (C2) nice things that I learned in school and such.
In very large tables, the interpolation will get lousy because the resolution of floats gets too close to the resolution of the table indices themselves (that is, there are not enough fractions between two consecutive integers). But this does not happen at the beginning of the table. On average, though, or on worst-case (which often matters), bigger tables make things worse in pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Wed, 2008-06-11 at 12:52 +0100, Andy Farnell wrote:
I'm really looking forward to giving this the 'ear test'.
Maybe I'm growing old but differerences in interpolation methods are very subtle to my perception. What would be the hard case to test it? It would be when the signal is greatly transposed, right?
Remember when I tested your stab at sinc interpolation Charles, I honestly couldn't hear an big difference, there was one, but hard to define.
yo, i recorded a snare drum sound (from the netpd-patch bon-minidrm) into a table and made a comparison, while playing the sample at different speeds. i chose the snare, because it has lots of noise in the high frequencies and i assume, this will probably rather make any interpolation effects audible. when playing at 0.05x original speed, the differences between [tabread4~] and [tabread4c~] are not so subtle anymore. [tabread4~] sounds almost 'gameboyish' compared to [tabread4c~].
without any scientific approach and without any judgement about which of those two methods gives the result, that comes closer to the imaginary function of the original soundfile, it's becoming obvious, that cubic interpolation sounds more what one would expect from an audio interpolation algorithm (i.e. less audible artefacts). the difference is not only clearly visible, but also audible, especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Yep, definitely improved for downwards transposition.
So, I suppose [tabread4c~] should be the choice for musical samplers, with [tabread4~] being good enough for playing back files at their original rate, and [tabread~] for control signals and suchlike.
On Mon, 16 Jun 2008 00:45:51 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though.
Sounds like tabread4c~ is very useful, but I would be hesistant to
replace the built-in tabread4~ with it, since it would change the
sound of existing pieces that use it. Perhaps there could be a
library of different interpolating table reading functions?
.hc
On Jun 16, 2008, at 1:15 AM, Andy Farnell wrote:
Yep, definitely improved for downwards transposition.
So, I suppose [tabread4c~] should be the choice for musical samplers, with [tabread4~] being good enough for playing back files at their original rate, and [tabread~] for control signals and suchlike.
On Mon, 16 Jun 2008 00:45:51 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though.
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Sounds like tabread4c~ is very useful, but I would be hesistant to
replace the built-in tabread4~ with it, since it would change the
sound of existing pieces that use it. Perhaps there could be a
library of different interpolating table reading functions?
Maybe one could select the interpolation method to use with a message and argument to [tabread4~] and let the old one be the default.
Ciao
Frank Barknecht _ ______footils.org__
Hans-Christoph Steiner a écrit :
Sounds like tabread4c~ is very useful, but I would be hesistant to
replace the built-in tabread4~ with it, since it would change the
sound of existing pieces that use it. Perhaps there could be a
library of different interpolating table reading functions?
yes, that was my plan c
.hc
On Jun 16, 2008, at 1:15 AM, Andy Farnell wrote:
Yep, definitely improved for downwards transposition.
So, I suppose [tabread4c~] should be the choice for musical samplers, with [tabread4~] being good enough for playing back files at their original rate, and [tabread~] for control signals and suchlike.
On Mon, 16 Jun 2008 00:45:51 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though.
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, Jun 17, 2008 at 12:22 PM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
Hans-Christoph Steiner a écrit :
Sounds like tabread4c~ is very useful, but I would be hesistant to replace the built-in tabread4~ with it, since it would change the sound of existing pieces that use it. Perhaps there could be a library of different interpolating table reading functions?
yes, that was my plan c
If I can figure out ways to improve the anti-aliasing table read (tabread4a~)--I'd also like to contribute to the tabreadx~ library. I've been stuck on it for a while, trying to figure out ways to reduce the computational load. It works, but it's still quite literal--it does exactly what you tell it to, and the computations grow linearly with speed.
Chuck
.hc
On Jun 16, 2008, at 1:15 AM, Andy Farnell wrote:
Yep, definitely improved for downwards transposition.
So, I suppose [tabread4c~] should be the choice for musical samplers, with [tabread4~] being good enough for playing back files at their original rate, and [tabread~] for control signals and suchlike.
On Mon, 16 Jun 2008 00:45:51 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
especially when transposing very low downwards. i couldn't hear any difference, when transposing upwards, though.
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 16 Jun 2008, Andy Farnell wrote:
with [tabread4~] being good enough for playing back files at their original rate,
If you are going to playback at original rate, [tabread4] is both useless and 10 times slower than [tabread]. All that [tabread4] is good at, is playing back at different non-original rates (that is anything else than +1 times and -1 times).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Yes that'right, hmm I guess I knew that but said it in a woolly way
Amend that to
[tabread~] - "play back at exactly" the original rate [tabread4~] - "play back at close to the orginal rate" [tabread4c~] - "play back with wider transposition"
On Mon, 23 Jun 2008 00:50:44 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 16 Jun 2008, Andy Farnell wrote:
with [tabread4~] being good enough for playing back files at their original rate,
If you are going to playback at original rate, [tabread4] is both useless and 10 times slower than [tabread]. All that [tabread4] is good at, is playing back at different non-original rates (that is anything else than +1 times and -1 times).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Jun 23, 2008, at 7:52 AM, Andy Farnell wrote:
On Mon, 23 Jun 2008 00:50:44 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 16 Jun 2008, Andy Farnell wrote:
with [tabread4~] being good enough for playing back files at their original rate,
If you are going to playback at original rate, [tabread4] is both
useless and 10 times slower than [tabread]. All that [tabread4] is good
at, is playing back at different non-original rates (that is anything
else than +1 times and -1 times)._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Yes that'right, hmm I guess I knew that but said it in a woolly way
Amend that to
[tabread~] - "play back at exactly" the original rate [tabread4~] - "play back at close to the orginal rate" [tabread4c~] - "play back with wider transposition"
Perhaps these could have more descriptive names, especially if there
was a "tabread", etc. library. Some quick ideas:
[tabread_tweak~] [tabread_transpose~]
.hc
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television
On Mon, 23 Jun 2008 11:38:27 +0200 Hans-Christoph Steiner hans@eds.org wrote:
Perhaps these could have more descriptive names, especially if there
was a "tabread", etc. library. Some quick ideas:[tabread_tweak~] [tabread_transpose~]
Hard to argue against, but I'm such a fan of Vanilla style compactness and brevity. :)
This may have been discussed before, but to widen the discussion...
I got thinking about a great discussion I read on music-dsp or harmony-central (sorry can't find the ref now) about sampler design. Since , as matju points out there's no interpolation advantage at unity pitch I remembered the hoopla proposed to make 'one size fits all' compromise designs. The conclusions were something indicationg that a general purpose [sampler~] (?) object would use the approach taken by Emu or Native Instruments, selecting the best method depending on the case.
There are maybe 5 classes, each requiring different approaches for quality results.
No transposition - very common for drum machines etc
Very small transpositions - microtonal variations on existing scale multisamples
Transpositions down within a fifth
Transpositions down greater than a fifth
Transpositions up
With the interpolation choices being none, linear, cubic, oversampled sinc and several variations of decimation/resampling schemes.
I'm not sure where 'very small' transpositions fit into that, aren't they actually a difficult case?
When people talk about the 'sound quality' of Pd I suspect they are more casual musical users who largely do sample based work. It would be great to have a whole suite of [tabreadX~] for the programmers. But for more casual users I think extended might greatly benefit from a 'just works' [sampler~] object. You could give it arguments along the lines of polyphony, outputs etc... It could even do multi-sample (with many tables). Add that to a file reader [soundfiler-kontakt] or [soundfiler-akai] to automatically generate the tables for [sampler~] and Pd would become quite attractive to a larger user base I think.
a.
.hc
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television
On Jun 23, 2008, at 1:01 PM, Andy Farnell wrote:
On Mon, 23 Jun 2008 11:38:27 +0200 Hans-Christoph Steiner hans@eds.org wrote:
Perhaps these could have more descriptive names, especially if there was a "tabread", etc. library. Some quick ideas:
[tabread_tweak~] [tabread_transpose~]
Hard to argue against, but I'm such a fan of Vanilla style compactness and brevity. :)
This compactness only really helps speed up the typing of code. It
hinders the reading of code and the learning of code. Plus it means
that us mere mortals, who cannot remember what "c" in [tabread4c~]
means, it means we have to constantly ride the reference pages rather
than just writing code.
Trading all this for typing a few less keystrokes seems to me a very
bad deal. Apparently, people who use Smalltalk, Java, Python, Ruby,
Obj-C and even sometimes C++ seem to agree.
.hc
This may have been discussed before, but to widen the discussion...
I got thinking about a great discussion I read on music-dsp or
harmony-central (sorry can't find the ref now) about sampler design. Since , as
matju points out there's no interpolation advantage at unity pitch I remembered the
hoopla proposed to make 'one size fits all' compromise designs. The
conclusions were something indicationg that a general purpose [sampler~] (?)
object would use the approach taken by Emu or Native Instruments, selecting the
best method depending on the case.There are maybe 5 classes, each requiring different approaches for
quality results.No transposition - very common for drum machines etc
Very small transpositions - microtonal variations on existing scale multisamples
Transpositions down within a fifth
Transpositions down greater than a fifth
Transpositions up
With the interpolation choices being none, linear, cubic,
oversampled sinc and several variations of decimation/resampling schemes.I'm not sure where 'very small' transpositions fit into that, aren't they actually a difficult case?
When people talk about the 'sound quality' of Pd I suspect they are
more casual musical users who largely do sample based work. It would be great to have a whole suite of [tabreadX~] for the programmers. But
for more casual users I think extended might greatly benefit from a
'just works' [sampler~] object. You could give it arguments along the lines of
polyphony, outputs etc... It could even do multi-sample (with many tables).
Add that to a file reader [soundfiler-kontakt] or [soundfiler-akai] to
automatically generate the tables for [sampler~] and Pd would become quite
attractive to a larger user base I think.a.
.hc
-- Use the source
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television-- Use the source
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
On Mon, 23 Jun 2008 13:18:11 +0200 Hans-Christoph Steiner hans@eds.org wrote:
This compactness only really helps speed up the typing of code. It
hinders the reading of code and the learning of code. Plus it means
that us mere mortals, who cannot remember what "c" in [tabread4c~]
means, it means we have to constantly ride the reference pages rather
than just writing code.Trading all this for typing a few less keystrokes seems to me a very
bad deal. Apparently, people who use Smalltalk, Java, Python, Ruby,
Obj-C and even sometimes C++ seem to agree.
Can't disagree with any of that. You're absolutely right.
I have had rather a special case interest in compact code - writing the sound design book. Many diagrams would have been impossible to typeset or fit onto a page if Pd used long object names.
You might think "Ah heck, what difference a few characters makes?!" But when you multiply that by 20, 30, 40 objects in a patch the real-estate issues get quite tough. I've spent hours refactoring and shuffling patches about to make them presentable.
On Mon, 23 Jun 2008, Hans-Christoph Steiner wrote:
This compactness only really helps speed up the typing of code. It hinders the reading of code and the learning of code. Plus it means that us mere mortals, who cannot remember what "c" in [tabread4c~] means, it means we have to constantly ride the reference pages rather than just writing code. Trading all this for typing a few less keystrokes seems to me a very bad deal. Apparently, people who use Smalltalk, Java, Python, Ruby, Obj-C and even sometimes C++ seem to agree.
The difference being that in other languages you can use word wrap. In Pd you can't do the moral equivalent of word wrap across objects, or else you weird up the positions of the wires. Pd users spend more time on layout than other programmers, even more than those who like to argue about where they put the braces. There are more things to consider and worry about when doing Pd layout than C++ layout.
Also, object contents are written horizontally AND people are much used to hate horizontal scrollbars... such a combination reduces the ability to manoeuvre, compared to a system in which aspect ratio of components is more like 1:1 (squares, circles). Elongated objects are harder to organise in a way where they don't conflict with each other (as in the game of Klotski)
The interaction of object width with inlets and outlets is also bad... wide objects may require more vertical spacing, to avoid nearly-horizontal patchcords in many cases, and contrary to the problem of objects too narrow, you never can make an object narrower by forcing the word-wrap of inside a box. Newlines, tabs and other whitespace are not saved, contrary to all languages that you listed above.
Being faced with lack of options in making nice patch layout, causes people to tend to value shorter names in Pd than in other languages.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mon, 2008-06-23 at 06:52 +0100, Andy Farnell wrote:
Yes that'right, hmm I guess I knew that but said it in a woolly way
Amend that to
[tabread~] - "play back at exactly" the original rate [tabread4~] - "play back at close to the orginal rate" [tabread4c~] - "play back with wider transposition"
i don't see any justification to keep [tabread4~] in this list. cyrille once mentioned that his new class isn't computationally more expensive. if there is a difference between [tabread4~] and [tabread4c~], then it is, that [tabread4c~] is _better_ than [tabread4~] (according to some previous posts regarding this subject). the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Mon, June 23, 2008 2:17 pm, Roman Haefeli wrote:
the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo.
Witch is a good enough reason to keep it, imho.
I much prefer Frank's suggestion. I.e. using the tabread4 name for a /class/ that offered a bunch of /methods/ - f.x. one like how tabread4 does now and one like how tabread4c.
On Mon, 2008-06-23 at 14:35 +0200, Steffen Juul wrote:
On Mon, June 23, 2008 2:17 pm, Roman Haefeli wrote:
the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo.
Witch is a good enough reason to keep it, imho.
i wasn't proposing to deprecate it, but i was only saying, it is the _only_ reason to keep it i can think of.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Jun 23, 2008, at 2:58 PM, Roman Haefeli wrote:
On Mon, 2008-06-23 at 14:35 +0200, Steffen Juul wrote:
On Mon, June 23, 2008 2:17 pm, Roman Haefeli wrote:
the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd
behaviour, imo.Witch is a good enough reason to keep it, imho.
i wasn't proposing to deprecate it, but i was only saying, it is the _only_ reason to keep it i can think of.
"tabread4~" isn't such a great name that it should be used for the
new one. Why not use a more descriptive name for the new one? Also,
changing the code of tabread4~ will change the sound quality of a
piece. I think it is very important to keep the same sound quality
since many people have spent a lot of time building patches around
tabread4~ and like the way those patches sound.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hans-Christoph Steiner wrote:
"tabread4~" isn't such a great name that it should be used for the
new one.
hmm, from my elitist point of view, [tabread4~] tells me something about how this object works (its reading a table using 4 point interpolation) rather than [tabread_tweak~] which tells me exactly nothing apart from being a modified version of [tabread~] which might do what i want or not.
certainly the exact meaning of the elements "tab" "read" "4" and "~" is something you have to get used to or learn by heart. but at least they make sense, once you know them.
this might be the reason why i prefer [lop~] over [cool_filter~] and Pd over reactor.
fgmasdr IOhannes
On Jun 24, 2008, at 11:36 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
"tabread4~" isn't such a great name that it should be used for
the new one.hmm, from my elitist point of view, [tabread4~] tells me something
about how this object works (its reading a table using 4 point
interpolation) rather than [tabread_tweak~] which tells me exactly
nothing apart from being a modified version of [tabread~] which
might do what i want or not.certainly the exact meaning of the elements "tab" "read" "4" and
"~" is something you have to get used to or learn by heart. but at
least they make sense, once you know them.this might be the reason why i prefer [lop~] over [cool_filter~]
and Pd over reactor.fgmasdr IOhannes
"4" stands for 4-point interpolation, that is true. But there are
many algorithms for 4-point interpolation, as this thread as laid
bare. tabread4~ could also describe something that reads 4 values
and averages them, it could also be the 4th version of tabread~.
Those are all existing naming conventions in Pd.
Feel free to critique my suggestions, but it isn't really productive
until there are suggestions for how to do it differently, rather than
merely saying my suggestion is bad.
How about putting the algorithm name in there somehow?
.hc
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
"4" stands for 4-point interpolation, that is true. But there are
many algorithms for 4-point interpolation, as this thread as laid
bare. tabread4~ could also describe something that reads 4 values
and averages them, it could also be the 4th version of tabread~.
Those are all existing naming conventions in Pd.
true that "4" doesn't say much about the interpolation alogrithm and that is definitely a weakness in the current naming scheme. it was not my intention to say that the current scheme is the non-plus-ultra in sophistication. it, however, was my intention to say that [tabread_tweak~] is one of the worst possible names i could think of. i do not say that this is is "constructive" criticism, rather i meant it as a preventive criticism.
gmsdfr IOhannes
On Tue, 24 Jun 2008, IOhannes m zmoelnig wrote:
true that "4" doesn't say much about the interpolation alogrithm and that is definitely a weakness in the current naming scheme.
Well, I'd have expected "4" to be a cubic spline algorithm, because it uses a sliding window of 4 samples, polynomial interpolation is pretty much the default, 4-point polynomial leads to cubic curves (using Lagrange or not), and beyond having a continuous curve (C0) and continuous derivative (C1), it's also nice to have a continuous second-derivative (C2). All this leading to basically one specific formula, which [tabread4] doesn't use, but which I assumed [tabread4] was using, until Roman told me that Cyrille had looked at it closely and found it to be non-C1.
(I made a mistake while talking to Roman. I said it's only C1, but the thing is that first derivatives are the last derivatives to be chosen according to samples. Second derivatives are chosen so that they fall to zero at every junction of pieces, and never anything else than zero. It's like that because there are 4 degrees of freedom, which are used up for start & end points of f & f'... that's 4, so f''(0) and f''(1) can't be set by variables... but it can be set by constants.)
All this to say that I don't think that the current interpolator deserved to be called THE "4", because there's a more generally useful interpolator that uses up the same power and thus would've been a much better choice for a default. The point of a default value or default algorithm is so that you need to specify a non-default as seldom as possible, and an unqualified "4" looks like a default to me (the name of the algorithm is implied)
it, however, was my intention to say that [tabread_tweak~] is one of the worst possible names i could think of. i do not say that this is is "constructive" criticism, rather i meant it as a preventive criticism.
It's like the names of the codecs in Quicktime-related GUIs... they all come out with different names than what the rest of the world is calling them... I don't have any names off the top of my head anymore, but it sure is/was confusing.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
"4" stands for 4-point interpolation, that is true. But there are
many algorithms for 4-point interpolation, as this thread as laid
bare. tabread4~ could also describe something that reads 4 values
and averages them, it could also be the 4th version of tabread~.
Those are all existing naming conventions in Pd.
I'm still fond of using only a single [tabread4~] object and being able to specify the type of 4-point interpolation to use with a [interpolate cubic( message or so. Additionally with a "-interpolate cubic" argument, maybe. Less strain on the global namespace and backwards compatible.
Ciao
Frank Barknecht _ ______footils.org__
I agree, being able to specify interpolation via an inlet message
would be great (from my users perspective).
Plus, deciding you want better interpolation (or none at all) in any
given abstraction would not require the touching of code, which is a
big + in my opinion. Sometimes I may want quality, sometimes not, and
other times I don't know yet or might want to change it on the fly.
That's what always bugged me about Reaktor's table object, you have to
right-click on the table in the setup and enable interpolation
manually, which to me is the equivalent and equally annoying to
specifying a different object in Pd. If you have many of these in
your app hunting is not very fun.
Cheers m8s, ~brandon
On Jun 24, 2008, at 10:25 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
"4" stands for 4-point interpolation, that is true. But there are many algorithms for 4-point interpolation, as this thread as laid bare. tabread4~ could also describe something that reads 4 values and averages them, it could also be the 4th version of tabread~. Those are all existing naming conventions in Pd.
I'm still fond of using only a single [tabread4~] object and being able to specify the type of 4-point interpolation to use with a [interpolate cubic( message or so. Additionally with a "-interpolate cubic" argument, maybe. Less strain on the global namespace and backwards compatible.
Ciao
Frank Barknecht _
______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I disagree entirely with the trend of this discussion towards naming or methods to choose an interpolation method.
We need not get ahead of ourselves, when we don't even know if it's a "better tabread" (like the name of this discussion). Let's make sure this thing is solid and finds good usage before expanding the tabread4~ code with extra methods.
It's nice to have descriptive names for the different interpolation schemes, but there is a big difference for naming them according to what they do or how they're used, as Matju said. I see no problem with shortening the names, because it's not practical to name these things concisely, e.g. "tabread4_continuous_first_derivative~" or "tabread4_anti_aliasing~"
So, what's wrong with tabread4c~ or tabread4a~? plenty of alternatives, but really, this is short and memorable, while keeping with the notion that these are small differences from the original tabread4~
I think it's best to consider making a library of tabread4~ alternatives, and later consider moving the different interpolation schemes to tabread4~ methods, if it's worth-while.
Chuck
On Tue, Jun 24, 2008 at 4:12 PM, bsoisoi bsoisoi@mac.com wrote:
I agree, being able to specify interpolation via an inlet message would be great (from my users perspective). Plus, deciding you want better interpolation (or none at all) in any given abstraction would not require the touching of code, which is a big + in my opinion. Sometimes I may want quality, sometimes not, and other times I don't know yet or might want to change it on the fly. That's what always bugged me about Reaktor's table object, you have to right-click on the table in the setup and enable interpolation manually, which to me is the equivalent and equally annoying to specifying a different object in Pd. If you have many of these in your app hunting is not very fun. Cheers m8s, ~brandon
On Jun 24, 2008, at 10:25 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
"4" stands for 4-point interpolation, that is true. But there are
many algorithms for 4-point interpolation, as this thread as laid
bare. tabread4~ could also describe something that reads 4 values
and averages them, it could also be the 4th version of tabread~.
Those are all existing naming conventions in Pd.
I'm still fond of using only a single [tabread4~] object and being able to specify the type of 4-point interpolation to use with a [interpolate cubic( message or so. Additionally with a "-interpolate cubic" argument, maybe. Less strain on the global namespace and backwards compatible.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 24 Jun 2008, Charles Henry wrote:
I see no problem with shortening the names, because it's not practical to name these things concisely, e.g. "tabread4_continuous_first_derivative~" or "tabread4_anti_aliasing~"
"continuous first derivative" is listed as "continuously differentiable" in the list of meanings of this abbreviation: http://en.wikipedia.org/wiki/C1
I think it's best to consider making a library of tabread4~ alternatives, and later consider moving the different interpolation schemes to tabread4~ methods, if it's worth-while.
I don't think that more than one alternative will be necessary. For 4-point table lookups that go through all the original points, I don't know why anyone would aim lower than a C2 piecewise-polynomial. Unfortunately, it would be somewhat too late to just call it [tabread4~]. Or not.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Tue, Jun 24, 2008 at 9:24 PM, Mathieu Bouchard matju@artengine.ca wrote:
I don't think that more than one alternative will be necessary. For 4-point table lookups that go through all the original points, I don't know why anyone would aim lower than a C2 piecewise-polynomial. Unfortunately, it would be somewhat too late to just call it [tabread4~]. Or not.
How low is too low? hmmm.... tabread4~ is deficient as Cyrille pointed out, because the resulting function is not continuously differentiable (thanks for the correction). So, what characteristics would be best for a "fast" interpolating function?
When we have an interval between samples, we wish to fit a polynomial (because it's fast, I guess) that satisfies our constraints. We could specify the polynomial has the same values at x[-1],x[0], x[1], x[2] (tabread4~). Four constraints, determines a cubic polynomial, works out as a linear algebra problem.
or we could set x[0],x[1] and x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2 again, 4 constraints, cubic polynomial, etc...
or another 4 point scheme, with continuous 2nd derivative setting x[0], x[1], x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2 and x''[0]=x[1]-2*x[0]+x[-1] and x''[1]=x[2]-2*x[1]+x[0] 6 constraints, 5th degree polynomial
and if you additionally wanted it to actually go through x[-1] and x[2], it would be 7th degree
So, even for 4-point interpolation, there are some options that could all be called tabread4~.
But not all possibilities are worth analyzing... I'm not even sure what kind of method to use to narrow the field.
Chuck
On Tue, 24 Jun 2008, Charles Henry wrote:
On Tue, Jun 24, 2008 at 9:24 PM, Mathieu Bouchard matju@artengine.ca wrote:
I don't think that more than one alternative will be necessary. For 4-point table lookups that go through all the original points, I don't know why anyone would aim lower than a C2 piecewise-polynomial. Unfortunately, it would be somewhat too late to just call it [tabread4~]. Or not.
How low is too low? hmmm....
I fucked up here. To get a C2 curve you may need to solve an equation system covering the whole table (!). Anyhow, a C1 system is fine enough for most uses, and it would be already much better than pd's.
The thing is that you can only match the 2nd derivatives if you let the 1st derivatives just match but freely float. Then there will be one curve going through all points of the whole table supposing that the 2nd derivative is zero at the beginning and end of the table. Clearly this is a wholly different game because you need to compute a 2nd table to remember what the 1st derivatives are supposed to be and then you can't change anything in the 1st table without recomputing the 2nd table from scratch, or something.
When we have an interval between samples, we wish to fit a polynomial (because it's fast, I guess) that satisfies our constraints. We could specify the polynomial has the same values at x[-1],x[0], x[1], x[2] (tabread4~).
No, you don't set those 4 constraints because else you will get exactly the same polynomial that tabread4~ already figures out, and we know that it is not C1. You need to drop x[-1] and x[2] as conditions.
or we could set x[0],x[1] and x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2 again, 4 constraints, cubic polynomial, etc...
Seems reasonable. What I want has to have constraints on x'[0] and x'[1]. Those would be a possibility. The problem is that it uses a gap of 2 samples instead of one, so it uses a "blurry" derivative, but the alternative is to have to pick between forward-difference and backwards-difference. The "blurry" derivative happens to be the average of the 1-sample forward-difference and backward-difference.
and x''[0]=x[1]-2*x[0]+x[-1] and x''[1]=x[2]-2*x[1]+x[0] 6 constraints, 5th degree polynomial
I think that the replacement for tabread4~ should be another cubic, so that it takes almost the same time to compute it. What I said about C2 was based on a mistaken reading of webpages trying to refresh myself on splines. I should've been more careful.
and if you additionally wanted it to actually go through x[-1] and x[2], it would be 7th degree
No, you shouldn't care about matching those extra points because anyway only the curve between x[0] and x[1] is used. The two outer points should be used only to figure out what derivatives to use.
But not all possibilities are worth analyzing... I'm not even sure what kind of method to use to narrow the field.
The "blurry" derivative above seems to be fine... I'd have to try it, but I should be working on other things now. I suppose that Cyrille already has everything figured out anyway. I just feel like talking about math sometimes... ;)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Thu, Jun 26, 2008 at 11:18 AM, Mathieu Bouchard matju@artengine.ca wrote:
I fucked up here. To get a C2 curve you may need to solve an equation system covering the whole table (!). Anyhow, a C1 system is fine enough for most uses, and it would be already much better than pd's.
The thing is that you can only match the 2nd derivatives if you let the 1st derivatives just match but freely float. Then there will be one curve going through all points of the whole table supposing that the 2nd derivative is zero at the beginning and end of the table. Clearly this is a wholly different game because you need to compute a 2nd table to remember what the 1st derivatives are supposed to be and then you can't change anything in the 1st table without recomputing the 2nd table from scratch, or something.
I get what you're saying now. I had to read it a couple times through to see :) You're referring to piecewise cubic polynomials, right? We would wind up with an overdetermined system of equations if we didn't float the 1st *and* 2nd derivatives, which would come out as a linear algebra problem of the size of the table.
but I think it gets even worse. There could be a non-zero null space to the problem. There are infinite solutions to interpolate a table full of zeros, with these conditions. What a mess :)
or we could set x[0],x[1] and x'[0]=(x[1]-x[-1])/2 and x'[1]=(x[2]-x[0])/2 again, 4 constraints, cubic polynomial, etc...
Seems reasonable. What I want has to have constraints on x'[0] and x'[1]. Those would be a possibility. The problem is that it uses a gap of 2 samples instead of one, so it uses a "blurry" derivative, but the alternative is to have to pick between forward-difference and backwards-difference. The "blurry" derivative happens to be the average of the 1-sample forward-difference and backward-difference.
By expanding it out to more points, we could use a more accurate calculation of the derivative. There's always a frequency dependent effect on the accuracy of 1st derivative approximations.
For example, backwards difference: x' ~= x[n] - x[n-1]
X'[z] = X[z] ( 1 - z^-1)
Which has spectrum, X'[w]=1-e^(-j*w) |X'[w]|^2=(1-cos(w))^2+sin(w)^2, phase (X'[w])=arctan( sin(w)/(1-cos(w)) )
our ideal system has X'[w]=j*w
Central divided difference x' ~= (x[n+1] - x[n-1])/2
X'[z] = X[z] ( z - z^-1)/2
Which has spectrum, X'[w]=(e^(j*w)-e^(-j*w))/2
X'[w]=j*sin(w)
It still has trouble with the high frequencies. So there might be some value in expanding the number of points to include better approximations.
and x''[0]=x[1]-2*x[0]+x[-1] and x''[1]=x[2]-2*x[1]+x[0] 6 constraints, 5th degree polynomial
I think that the replacement for tabread4~ should be another cubic, so that it takes almost the same time to compute it. What I said about C2 was based on a mistaken reading of webpages trying to refresh myself on splines. I should've been more careful.
Yeah, a cubic polynomial makes the most sense for small changes. I haven't ever heard of people interpolating 4 points with a 5th degree polynomial.... but I think I could make it work....
The "blurry" derivative above seems to be fine... I'd have to try it, but I should be working on other things now. I suppose that Cyrille already has everything figured out anyway. I just feel like talking about math sometimes... ;)
It's all good by me :)
Chuck
On Fri, 27 Jun 2008, Charles Henry wrote:
I get what you're saying now. I had to read it a couple times through to see :) You're referring to piecewise cubic polynomials, right?
Yes, I'm always assuming that piecewise-cubics is all that we'll need.
We would wind up with an overdetermined system of equations if we didn't float the 1st *and* 2nd derivatives, which would come out as a linear algebra problem of the size of the table.
Yes, which is why we don't want to do that.
but I think it gets even worse. There could be a non-zero null space to the problem. There are infinite solutions to interpolate a table full of zeros, with these conditions. What a mess :)
In that case (which is when the algebra problem has the size of the table), there are two missing conditions, and then when you set them to x''[0]=0 and x''[last]=0, it is called «natural cubic spline».
By expanding it out to more points, we could use a more accurate calculation of the derivative.
Yes, but we don't want to get into that for this particular application, because the point is to be fast, and 4-point is the first N-point that makes sense (enough interpolation). Well, there is also 3-point, as used in Tk's Bézier splines (-smooth 1), but... hmm... what is possible with 3-point ?
There's always a frequency dependent effect on the accuracy of 1st derivative approximations.
And on the accuracy of all Nth derivative approximations.
So there might be some value in expanding the number of points to include better approximations.
Perhaps, but there is still a need for something fairly expedient to be used as the main interpolation method in pd.
Yeah, a cubic polynomial makes the most sense for small changes. I haven't ever heard of people interpolating 4 points with a 5th degree polynomial.... but I think I could make it work....
It could work, but I don't know how much it's worth it. Higher derivatives of anything quite discrete will be rather jumpy. The Nth derivative of a white noise sample doubles its RMS at every derivation, for example, but when looking just at the near-Nyquist hiss, it's much worse than that. The more you use derivatives, the trickier it gets.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
bsoisoi wrote:
I agree, being able to specify interpolation via an inlet message would be great (from my users perspective).
hmm, i am not totally convinced (but actually don't care) as this leads to bloated objects which can just do everything and you specify what they should do via parameters. why do we have objects then?
That's what always bugged me about Reaktor's table object, you have to right-click on the table in the setup and enable interpolation manually, which to me is the equivalent and equally annoying to specifying a different object in Pd. If you have many of these in your app hunting is not very fun.
anyhow, now for something constructive: you can always create an abstraction [tabread_tweaked~] that is like
[inlet~] | [tabread~ $1] | [outlet~]
and use this abstraction. if you later decide that you do want interpolation just make the abstraction to be like
[inlet~] | [tabread4~ $1] | [outlet~]
et voila.
you could argue that then you would have to think of the variability beforehand; bit you would have to do this as well if you are using messages (unless you are up to hunting all the [tabread~] in your patch to add the special message)
fgmasdr IOhannes
Excellent point, don't listen to me! :)
From your example, I'm assuming you're hinting at including the
ability in this abstraction to switch interpolation schemes by
enabling/disabling sub-patched tabread~, tabread4~, and tabread4c~
objects via inlet messages or creation arguments.
In the end, I would probably only use a tabread4c~ type object in
special circumstances given tabread4~ is good enough. So whatever you
decide to do I'm sure it's going to be legit (as Pd rocks).
Cheers, ~Brandon
On Jun 24, 2008, at 6:06 PM, IOhannes m zmoelnig wrote:
hmm, i am not totally convinced (but actually don't care) as this
leads to bloated objects which can just do everything and you
specify what they should do via parameters. why do we have objects
then?
On Wed, 25 Jun 2008, IOhannes m zmoelnig wrote:
hmm, i am not totally convinced (but actually don't care) as this leads to bloated objects which can just do everything and you specify what they should do via parameters. why do we have objects then?
Objects and classes also have other benefits apart from making people believe that they should act a special way just because they are in presence of objects... if that's a benefit...
I don't know of any docs that explain what is good and bad taste in designing pd object class interfaces. This is a topic that is always outside the scope of whichever pd workshop anyone ever takes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
bsoisoi wrote:
I agree, being able to specify interpolation via an inlet message would be great (from my users perspective).
hmm, i am not totally convinced (but actually don't care)
Is anyone else besides me reminded of a "color of bike shed" discussion?
as this leads to bloated objects which can just do everything and you specify what they should do via parameters. why do we have objects then?
However in this case I think, it does make sense to keep it in a single object and set interpolation through messages: all suggested tabread4~ variants do a table read using 4 table points for interpolation, so all of them could be named tabread4~. They only differ in the actual formula in use. Variants of 4-point interpolation may also be useful in other objects like vd~ and tabosc4~. Here the same message interface could be used again, which is good for mnemonics.
Ciao
Frank Barknecht _ ______footils.org__
On 24/06/2008, at 12.17, Hans-Christoph Steiner wrote:
Feel free to critique my suggestions, but it isn't really productive until there are suggestions for how to do it differently, rather than merely saying my suggestion is bad.
Depends on what it is to be different from. If it is to be different
from the current state then it excludes the possibility to argue for
status quo.
Best wishes for a happy day.
On Thu, 26 Jun 2008, Damian Stewart wrote:
one of the pushes to me finally learning Pd was discovering that there was an object called [moses], and it did what it said it did.
We need a state-saving object class named [jesus].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
well, tabread4c~ is far from perfect, it has the same aliasing problem than tabread4~ and it create more distortion than tabread4~. (but in lower frequency).
one told me that modern commercial audio software can use 32 points shannon interpolation. http://en.wikipedia.org/wiki/Whittaker%C3%82%E2%80%93Shannon_interpolation_f...
i'd like to try that... it will be more expensive, but this is negligible on recent hardware, and sound quality worth it.
so, for now, i'll try different interpolation schematic, and we will see latter what to use...
cyrille
Roman Haefeli a écrit :
On Mon, 2008-06-23 at 06:52 +0100, Andy Farnell wrote:
Yes that'right, hmm I guess I knew that but said it in a woolly way
Amend that to
[tabread~] - "play back at exactly" the original rate [tabread4~] - "play back at close to the orginal rate" [tabread4c~] - "play back with wider transposition"
i don't see any justification to keep [tabread4~] in this list. cyrille once mentioned that his new class isn't computationally more expensive. if there is a difference between [tabread4~] and [tabread4c~], then it is, that [tabread4c~] is _better_ than [tabread4~] (according to some previous posts regarding this subject). the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Jun 23, 2008 at 8:23 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
well, tabread4c~ is far from perfect, it has the same aliasing problem than tabread4~ and it create more distortion than tabread4~. (but in lower frequency).
Strictly speaking, these interpolations don't create distortion in as much as they have a non-flat frequency response. No matter which method you use, the interpolation function can be re-written as a convolution, which is linear.
In my prior analysis of the tabread4~ impulse response, I obtained the following function for the impulse response.
g(t)=I-2,2(-1/6*|t|^3 - 2*t^2 - 11/6*|t| + 1) + I-1,1(2/3*|t|^3 - 2*t^2 + 4/3*|t|)
And it's fourier transform, where w=pi represents the Nyquist frequency. (by the way, the angular frequency notation greatly simplifies the calculus involved)
G(w)=(1/w^2)*[1/3*cos(2w) - 4/3*cos(w) + 1] + (1/w^4)*[2*cos(2w)
- 8*cos(w) + 6]
This function falls off at a rate of at most -6 dB/octave (according to the 1/w^2 term). What you are referring to as distortion is not actually distortion, but aliasing and a non-flat frequency response. The spectrum of this function is pretty nice, but everything above pi rad/sec is aliased, which causes some additional frequencies, mostly high frequencies.
I'm reluctant to do the same for tabread4c~ because it takes several hours to do. If you come up with a good set of coefficients that seem to be pretty solid, I'll spare some time for the frequency response.
one told me that modern commercial audio software can use 32 points shannon interpolation. http://en.wikipedia.org/wiki/Whittaker%E2%80%93Shannon_interpolation_formula
i'd like to try that... it will be more expensive, but this is negligible on recent hardware, and sound quality worth it.
I doubt that it would be negligible. I do agree that it would find many applications, but not as a replacement for a fast, good-enough tabread.
32-point windowed sinc interpolation borders on anal retentive. Instead of that, it might be better to probe out what degree of fast polynomial interpolation will have a good-enough spectrum.
Chuck
so, for now, i'll try different interpolation schematic, and we will see latter what to use...
cyrille
Roman Haefeli a écrit :
On Mon, 2008-06-23 at 06:52 +0100, Andy Farnell wrote:
Yes that'right, hmm I guess I knew that but said it in a woolly way
Amend that to
[tabread~] - "play back at exactly" the original rate [tabread4~] - "play back at close to the orginal rate" [tabread4c~] - "play back with wider transposition"
i don't see any justification to keep [tabread4~] in this list. cyrille once mentioned that his new class isn't computationally more expensive. if there is a difference between [tabread4~] and [tabread4c~], then it is, that [tabread4c~] is _better_ than [tabread4~] (according to some previous posts regarding this subject). the only good reason to keep [tabread4~] in pd is to keep backwards compatibility with patches that exploit [tabread4~]'s wierd behaviour, imo.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
O can see how that could happen. I think the error in Lagrange is spread out over all frequencies whereas I can imagine other interpolation methods in which the error would be at frequencies closer to the original sound (and so much harder to perceive in a situation like the one you're working in).
cheers Miller
On Wed, Jun 11, 2008 at 12:05:34AM +0200, cyrille henry wrote:
ok, thanks for the answer. i understand what's in your book, but i found other references where cubic interpolation is used for a function that offer continuity of the 1st derivative.
i can understand that tabread4~ minimise the error when the table is large (when you play it faster than the original speed). but with a small table, or when you play it slower, the first derivative discontinuity create lot's of high frequency.
So, in this condition, the function i use offer a better quality. see in the svn externals/nusmuk/tab/tabosc4c~-help.pd for more.
cyrille
Miller Puckette a ?crit :
I believe "lagrange interpolation" just means polynomail. tabread4~ uses cubic interpolation... details are in http://crca.ucsd.edu/~msp/techniques/latest/book-html/node31.html
It may be that there's a better way to do 4-point interpoation than Lagrange but the way to find out would be by doing careful distortion measurements. In particular, I know there are ways do do 4-point interpolation that don't give discontinuous first derivatives, but I think most measures of distortion would indicate using the Lagrance one instead.
cheers Miller
On Tue, Jun 10, 2008 at 05:29:49PM +0200, cyrille henry wrote:
Charles Henry a ?crit :
On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i realized that the 4 points interpolation in tabread4~ (and tabosc4~) are not optimal.
Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad?
well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation.
i program a cubic interpolation, and the shape of the waveform is really different.
please compile the object and look at the help patch to see the difference.
i can also send waveforme picture if needed.
cyrille
Chuck
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of cyrille henry Sent: 10 June 2008 16:30 To: Charles Henry Cc: pd-list@iem.at Subject: Re: [PD] better tabread4~
Charles Henry a écrit :
On Tue, Jun 10, 2008 at 4:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
i realized that the 4 points interpolation in tabread4~
(and tabosc4~) are not optimal.
Please describe. I've analyze the interpolation formula too, and I think that it is a true cubic interpolation. Is the numerical accuracy bad?
well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation.
i program a cubic interpolation, and the shape of the waveform is really different.
Are we talking about 4-point polynomial interpolation versus cubic spline interpolation? These are indeed different.
On Tue, Jun 10, 2008 at 10:29 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
well, i think the tabread4~ interpolation is a lagrange interpolator (but i'm may be wrong). at least with tabread4~, the 1st derivative is not continuous, while it should be with a cubic interpolation.
The Lagrange interpolation scheme is not continuous, because it fits a polynomial through 4 points (-1, 0 ,1 , 2) and interpolates between 0 and 1. But when it goes to the next 4 points (0, 1, 2, 3), it fits another polynomial and interpolates between 1 and 2. So, the discontinuity in 1st derivative is at each sample.
i program a cubic interpolation, and the shape of the waveform is really different.
please compile the object and look at the help patch to see the difference.
i can also send waveforme picture if needed.
I'm having trouble compiling, due to the garray_getfloatwords symbol. Which version of Pd are you using?
I'd like to see the waveform and test it out. Here's my analysis of key points
(a=x[-1], b=x[0], c=x[1], d=x[2])
83 a0 = d - c - a + b; 84 a1 = a - b - a0; 85 a2 = c - a; 86 *out++ = ((a0*frac+a1)*frac+a2)*frac+b;
At frac=0, output should be b. Check!
At frac=1, output should be c
((a0*1+a1)*1+a2)*1+b =a0+a1+a2+b =d-c-a+b + a-b-(d-c-a+b) + c-a + b =d-c-a+b + a-b-d+c+a-b + c-a + b =d-c-a+b + 2a-2b+c-d + c-a + b =c
Check!
1st derivatives:
At frac=0, d/dx f(x) = c-a
(This quantity really ought to be (c-a)/2, but let's see how the rest comes out)
At frac=1,
d/dx f(x) = 3*(d-c-a+b) + 2*(a-b-d+c+a-b) + c-a =d-b
So, we've got 1st derivatives that match between samples. Check!
This looks like a really good plan. I might suggest some new coefficients to try:
a0=(3b-a-3c+d)/2 a1=a-5b/2+2c-d/2 a2=(c-a)/2
The only difference is the 1st derivatives are (c-a)/2 and (d-b)/2, respectively.
Maybe you could try a 5th-degree polynomial next and set the 2nd derivatives for continuity. This would involve 4-points as before, but it might introduce a ripple in the interpolation (cubic interpolation can't do that, since it only has two critical points).
I'm not keen on doing the spectral analysis, because it would take about 4 hours, to do it by hand.
There's something I would like to see (once I can compile it). I made a patch (attached) a while back to view the tabread4~ interpolation function (impulse response). Give it a try if you're inclined to do so, because it might surprise you.
Chuck
cyrille
Chuck
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hello,
Charles Henry a écrit :
On Tue, Jun 10, 2008 at 10:29 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
...
I'm having trouble compiling, due to the garray_getfloatwords symbol. Which version of Pd are you using?
vanilia 0.41.4
I'd like to see the waveform and test it out. Here's my analysis of key points
(a=x[-1], b=x[0], c=x[1], d=x[2])
83 a0 = d - c - a + b; 84 a1 = a - b - a0; 85 a2 = c - a; 86 *out++ = ((a0*frac+a1)*frac+a2)*frac+b;
At frac=0, output should be b. Check!
At frac=1, output should be c
((a0*1+a1)*1+a2)*1+b =a0+a1+a2+b =d-c-a+b + a-b-(d-c-a+b) + c-a + b =d-c-a+b + a-b-d+c+a-b + c-a + b =d-c-a+b + 2a-2b+c-d + c-a + b =c
Check!
1st derivatives:
At frac=0, d/dx f(x) = c-a
(This quantity really ought to be (c-a)/2, but let's see how the rest comes out)
At frac=1,
d/dx f(x) = 3*(d-c-a+b) + 2*(a-b-d+c+a-b) + c-a =d-b
So, we've got 1st derivatives that match between samples. Check!
This looks like a really good plan. I might suggest some new coefficients to try:
a0=(3b-a-3c+d)/2 a1=a-5b/2+2c-d/2 a2=(c-a)/2
ok, i don't have time for now to test anything. i'll have more time in 1 or 2 weeks.
The only difference is the 1st derivatives are (c-a)/2 and (d-b)/2, respectively.
Maybe you could try a 5th-degree polynomial next and set the 2nd derivatives for continuity. This would involve 4-points as before, but it might introduce a ripple in the interpolation (cubic interpolation can't do that, since it only has two critical points).
i tried a Hermite interpolation. it sound great, but i did not had time yet to explore the tension parametter.
here is the code if you wish to explore it.
I'm not keen on doing the spectral analysis, because it would take about 4 hours, to do it by hand.
There's something I would like to see (once I can compile it). I made a patch (attached) a while back to view the tabread4~ interpolation function (impulse response). Give it a try if you're inclined to do so, because it might surprise you.
attachement is a pict of the impulse response of tabread4~ and tabread4c~.
cyrille
Chuck
cyrille
Chuck
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andy Farnell -
Atwood, Robert C -
Brandon Zeeb -
bsoisoi
-
Charles Henry -
cyrille henry -
Damian Stewart -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Miller Puckette -
Roman Haefeli -
Steffen Juul