I think osc~ will fold over correctly... however, to hear 150 Hz. you would have to tune it to 44250 Hz (or indeed 43950), not 22200 which folds over to a (still inaudible) 21900. Miller
think that when one plays a 22200 freq at 44.1kHz sample rate, you will hear it as 21900 rather than 150. To reach 150, you have to go up higher to 43950 (= 44100-150). Chuck
That's because the example you give here isn't an example of the Nyquist theorem. The aliased frequencies 'fold back', rather than wrapping. It is like the Nyquist frequency is a mirror reflecting the signal's components back into the sub Nyquist range Jamie
# Thank you very much! I forget that the problem of sampled discrete signals is called "foldover", I thought that was "wrapping" like Jamie said. Sorry to keep you busy with my ignorance. (But on the way of investigating my problem, I learned much about controlling objects pricely.)
I wonder, which other objects would also benefit from becoming "special" in the way, vline~ is special. A possible model could be t3-lib, but for example the t3_bang object already is there in the form of the normal bang message, when its origin is a clock-derived message (as sent by metro etc.). So we don't need a "special" bang object. t3_bpe is the same as vline~ basically, t3_sig~ too, t3_metro, t3_del and t3_timer are the same as metro, del and timer now.
# Thank you for the info about t3-lib! [t3_metro] object is absolutely what I need. It's period has not a minimum acceptable value like [metro]. Their documentation is a bit awkward, but I figured out how to use it.
-ugur guney-
Hallo, sokratesla hat gesagt: // sokratesla wrote:
# Thank you for the info about t3-lib! [t3_metro] object is absolutely what I need. It's period has not a minimum acceptable value like [metro]. Their documentation is a bit awkward, but I figured out how to use it.
You should also be able to just make [metro] accept delays smaller 1 by changing line 110 in src/x_time.c to:
if (g < 0.0001) g = 0.0001;
or similar. I think, g (or x->x_deltime) should alway be a bit bigger than 0. Or maybe 0 would be acceptable as well?
Regarding t3-lib: There is a pdf floating around the web by Essl (or Eckel?) describing t3 for Max in more detail. I just cannot find it currently...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
sokratesla hat gesagt: // sokratesla wrote:
# Thank you for the info about t3-lib! [t3_metro] object is absolutely what I need. It's period has not a minimum acceptable value like [metro]. Their documentation is a bit awkward, but I figured out how to use it.
You should also be able to just make [metro] accept delays smaller 1 by changing line 110 in src/x_time.c to:
And of course another solution would be a clone of [metro] built using [del] as in attached patches.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jun 17, 2006, at 3:52 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
sokratesla hat gesagt: // sokratesla wrote:
# Thank you for the info about t3-lib! [t3_metro] object is
absolutely what I need. It's period has not a minimum acceptable value like
[metro]. Their documentation is a bit awkward, but I figured out how to use it.You should also be able to just make [metro] accept delays smaller 1 by changing line 110 in src/x_time.c to:
And of course another solution would be a clone of [metro] built using [del] as in attached patches.
How about making that a [metro] clone and adding it to abstractions/ purepd?
Also, I think it would be clearer to use [delay] rather than [del],
there's plenty of room in the patch, no abbreviations necessary. I
guess my DOS roots show, because I always think delete first when I
see [del].
.hc
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 17, 2006, at 3:52 AM, Frank Barknecht wrote:
And of course another solution would be a clone of [metro] built using [del] as in attached patches.
How about making that a [metro] clone and adding it to abstractions/ purepd?
Actually I think, [metro] should loose its 1 ms limit, then the abstraction wouldn't be necessary (and it can block Pd quite easily with very small delay times). IIRC Miller already hinted at the possibility for making metro's limit smaller.
Also, I think it would be clearer to use [delay] rather than [del],
there's plenty of room in the patch, no abbreviations necessary. I
guess my DOS roots show, because I always think delete first when I
see [del].
If it's in an abstraction, you won't see the [del] anyways. Smaller is beautifuller. ;)
But maybe I'm too used to use the abbreviations for often used objects. Reading [trigger anything anything] makes me as nervous as reading [del] must make you. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jun 17, 2006, at 5:33 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 17, 2006, at 3:52 AM, Frank Barknecht wrote:
And of course another solution would be a clone of [metro] built
using [del] as in attached patches.How about making that a [metro] clone and adding it to abstractions/ purepd?
Actually I think, [metro] should loose its 1 ms limit, then the abstraction wouldn't be necessary (and it can block Pd quite easily with very small delay times). IIRC Miller already hinted at the possibility for making metro's limit smaller.
[metro] should be fixed, but I also think that since you already
implemented a [metro] in Pd, it should be part of the purepd
collection as part of the effort to implement as much of Pd in Pd as
possible.
Also, I think it would be clearer to use [delay] rather than [del], there's plenty of room in the patch, no abbreviations necessary. I guess my DOS roots show, because I always think delete first when I see [del].
If it's in an abstraction, you won't see the [del] anyways. Smaller is beautifuller. ;)
But maybe I'm too used to use the abbreviations for often used objects. Reading [trigger anything anything] makes me as nervous as reading [del] must make you. ;)
The length difference between [del] and [delay] is quite trivial, but
the difference in readability is large. Sure, we are used to the
abbreviations, but maintainable code is as clean and easy to read as
possible.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
On Sun, 2006-06-18 at 14:57 -0400, Hans-Christoph Steiner wrote:
Actually I think, [metro] should loose its 1 ms limit, then the abstraction wouldn't be necessary (and it can block Pd quite easily with very small delay times). IIRC Miller already hinted at the possibility for making metro's limit smaller.
[metro] should be fixed, but I also think that since you already
implemented a [metro] in Pd, it should be part of the purepd
collection as part of the effort to implement as much of Pd in Pd as
possible.
i'm just curious ... why would it make sense to have a metro granularity smaller than the scheduler granularity of the operating system or the granularity of the dsp blocksize?
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i'm just curious ... why would it make sense to have a metro granularity smaller than the scheduler granularity of the operating system or the granularity of the dsp blocksize?
I'm not sure what exactly you mean with "granularity" here, but if you could only generate messages in steps of ~1.5 msec or 64 samples at 44.1kHz you could forget about using Pd to do techno music someone would actually dance to.
I don't know many use cases where you need a [metro 0.2] but I know many cases where you need an exact [metro 100.2]. Thankfully Pd provides this.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jun 17, 2006, at 5:33 PM, Frank Barknecht wrote:
How about making that a [metro] clone and adding it to abstractions/ purepd?
Actually I think, [metro] should loose its 1 ms limit, then the abstraction wouldn't be necessary (and it can block Pd quite easily with very small delay times). IIRC Miller already hinted at the possibility for making metro's limit smaller.
[metro] should be fixed, but I also think that since you already
implemented a [metro] in Pd, it should be part of the purepd
collection as part of the effort to implement as much of Pd in Pd as
possible.
I see the [delmetro] only as a temporary workaround for the rare cases, where you need really fast bangs. As there is a metro in purepd already, I don't see much sense in adding a clone.
I just wanted to illustrate the idiom of using delays in a metro-like fashion. This idiom becomes more interesting, when you want to do "metro"s with varying interval times for polyrhythms or for random rhythms like abstractions/nusmuk/rnd_metro.pd in CVS.
The length difference between [del] and [delay] is quite trivial, but
the difference in readability is large. Sure, we are used to the
abbreviations, but maintainable code is as clean and easy to read as
possible.
Yes, I understand, but I always use [del], I never write [delay]. Maybe because the "y" is in an awkward position on german keyboards. It is a bad habit. Like smoking.
One could fix it with:
$ perl -pi.bak -e 's/^(#X obj \d+ \d+) del\b/$1 delay/' *.pd
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Hans-Christoph Steiner -
sokratesla -
Tim Blechmann