Ahoy, ChucKists - I've just coded myself a perfectly serviceable metronome, and it works fine except for a small nagging thing in the MAUI. In my metronome, I have 2 toggle type buttons, "thirds" and "sixteenths". If one is on, the other is off, so i'm always subdividing the pulse one way or the other. As it is, if I turn "thirds" on and off, the "sixteenth" button dutifully goes off and on in a complementary way. If I do this, though: - toggle "thirds" on ("quarters" stays off) - toggle "quarters" on ("thirds" politely turns off) - toggle "thirds" on At this point they're *both* on. I can get back to a one-or-the- other state by fussing around and toggling the right combo of things, but i'd rather not do that. I've attached just the button-related code below - i've got two functions set up that are turning the other button on or off depending on whether or not they're off or on. It's bending my brain a bit to figure out why it sometimes behaves the way it does - any insights out there? thanks, as always, j. ------code------ MAUI_View view; view.size(400,200); MAUI_Button thirds; thirds.toggleType(); thirds.size(110,110); thirds.position(0, 100); thirds.name("thirds"); view.addElement(thirds); MAUI_Button sixteenths; sixteenths.toggleType(); sixteenths.size(110,110); sixteenths.position(110, 100); sixteenths.name("sixteenths"); view.addElement(sixteenths); view.display(); fun void controlThirds() { while (true) { thirds => now; sixteenths.state(0); <<<"thirds on">>>; thirds => now; sixteenths.state(1); <<<"thirds off">>>; } } fun void controlSixteenths() { while (true) { sixteenths => now; thirds.state(0); <<<"sixteenths on">>>; sixteenths => now; thirds.state(1); <<<"sixteenths off">>>; } } spork ~ controlThirds(); spork ~ controlSixteenths(); while (true) { 1::second => now; }
On Nov 14, 2007 3:53 AM, Jascha Narveson
fun void controlSixteenths() { while (true) {
sixteenths => now; !thirds.state() => thirds.state;
if (!thirds.state) <<<"sixteenths on">>>;
else <<<"sixteenths off">>>; } }
This way your shreds of this type no longer have their own "state" to keep track off which should help simplify problems like the one you have. This should also make it easier to do things like having one button turn off another, etc, by including that in the "if"clause. Again; I didn't get to try the graphical elements yet so I'm not 100% sure this will work but if it would it would considderably simplify your situation. Yours, Kas.
I've been examining a bit more the output of the fft and I am not sure about the spectrum magnitudes obtained after analysis. For instance, analysing the peaks of a SinOsc with unity gain in a similar manner as in examples/analysis/tracking/pitch-track.ck will print out values of max (maximum peak) around 0.26 instead of values near 1 (depending on the window used and the frequency. I've used a hamming window and a freq proportional to sample_rate/fft_size). Why is this? I've forgotten some of the implications of performing an FFT but I believe the values of the magnitudes obtained after an FFT are half the original value, but then, in the example above, one should obtain peak values near 0.5. What is the cause for this? Could it be that windowing is not normalised? I'd like to be sure of the values I should expect in order to set thresholds above which spectral peaks will be taken into account. thanks in advance, eduard
participants (3)
-
eduard aylon
-
Jascha Narveson
-
Kassen