3 timers with loop

[Nicolas605]

Time format is OK now and I have not the commutation noise on my Seven 64bits.

Many many thanks, great job

[ChrisHooker]

It seems like the highest number of loops the code component can run a counter is 16,777,216. (At 48K that's 5 min:49 sec, at 44.1K that's 6 min:20 sec.) While the floating point processing can handle numbers far higher than this, it seems this is the maximum number of loops that can be supported. (If you change the counter from adding 1 each loop to adding 2, you can see the max number is 33554432 (2x the original limit).)

I've never had the need to count so high before, so I wasn't aware of this. I tested it by creating an entirely new code block that only ran a counter. I don't really understand why it does this, but it does.
One way to overcome this limitation is to chain a second counter to start once the first is full:

counter1=counter1+1;
counter2=(counter1==16777216)&(counter2+1);

2 counters will allow you to reach a time of 11:37 sec. Keep adding counters until you have reached the desired limit.
I've attached an updated schematic to show the full implementation with 2 counters. (You also need a TotalCounter, which adds the two for comparison against TotalRunTime, for resetting the counters back to zero and start the cycle over.)

[tulamide]

It seems like the highest number of loops the code component can run a counter is 16,777,216. (At 48K that's 5 min:49 sec, at 44.1K that's 6 min:20 sec.) While the floating point processing can handle numbers far higher than this, it seems this is the maximum number of loops that can be supported. (If you change the counter from adding 1 each loop to adding 2, you can see the max number is 33554432 (2x the original limit).)

I've never had the need to count so high before, so I wasn't aware of this. I tested it by creating an entirely new code block that only ran a counter. I don't really understand why it does this, but it does.
One way to overcome this limitation is to chain a second counter to start once the first is full:

counter1=counter1+1;
counter2=(counter1==16777216)&(counter2+1);

2 counters will allow you to reach a time of 11:37 sec. Keep adding counters until you have reached the desired limit.
I've attached an updated schematic to show the full implementation with 2 counters. (You also need a TotalCounter, which adds the two for comparison against TotalRunTime, for resetting the counters back to zero and start the cycle over.)

That may have to do with the 23 + sign bits, a single precision float offers for the integer part of a number. Also, there are other ways to deal with it. I don't know how fast or slow they are, but for example you could count loops using modulo.

Code: Select all

counter = (counter + 1) % samplerate //counter for one second;
loopcount = loopcount + (counter == 0)&1 // counter for seconds;

[ChrisHooker]

Thanks for replying Tula.

If I understand correctly, the counter, despite being declared as a "float" is actually being handled as a 24-bit fixed-precision number, not a 32-bit floating-point variable, as the declaration "float" would imply?? And if that's the case, then why can we create another "float" counter and add its value to the maxed out 1st counter (and the code block handles that running sum as a third "float" fine), but we can't just continue adding +1 to the original counter?

I also just saw KG's post on his overclocking (http://www.dsprobotics.com/support/viewtopic.php?f=4&t=10397&view=unread#p38916), and how that is requiring a counter for hopped code... and I'm wondering if this issue will effect that.

[ChrisHooker]

By the way, nice use of the modulus! You wouldn't have to keep adding additional counters that way, it will handle a maximum of 185.9 years at 48k!! (16777216 samples * 16777216)

[tulamide]

If I understand correctly, the counter, despite being declared as a "float" is actually being handled as a 24-bit fixed-precision number, not a 32-bit floating-point variable, as the declaration "float" would imply?? And if that's the case, then why can we create another "float" counter and add its value to the maxed out 1st counter (and the code block handles that running sum as a third "float" fine), but we can't just continue adding +1 to the original counter?

I also just saw KG's post on his overclocking (http://www.dsprobotics.com/support/viewtopic.php?f=4&t=10397&view=unread#p38916), and how that is requiring a counter for hopped code... and I'm wondering if this issue will effect that.

Don't take my words as facts. I was just wondering, because 2^24 happens to be 16777216 - too much of a coincidence to not play some role in it. I hope that maybe KG or MyCo could shed some light here.

KG's counter might not be affected, as it is Assembler code. Or do you mean if your code is affected? You don't use hop, so it isn't. And it doesn't matter if a prior dsp code editor uses hop - your module is still run for each sample.

[Spogg]

I don't know how fast or slow they are, but for example you could count loops using modulo.

Just a note to say that modulo ( % ) doesn’t work in 3.081 and it’s a known issue and will be fixed in the next release.

For example see

viewtopic.php?f=4&t=4000&p=22736&hilit=modulo#p22736

I spent a long time on this once, until I finally did a search. Lesson for me: It’s not always something I did wrong

Cheers

Spogg

[tulamide]

That' s something I don't understand. Many people use 3.0.8.1, although it is filled with bugs and, as MyCo found out, Ruby runs at only half its speed (with same CPU load), due to being moved into a sub-thread.

The last really stable version is 3.0.6, and changes from that to newer versions were pretty much cosmetics, completely new features (that turned out to be buggy) and Assembler enhancements. Most people don't create their own Assembler modules. There really is no reason to stick to a version that is way more buggy, just because it has a higher version number!

Very off-topic, but I needed to say it!

EDIT: Just read a little more about it, and it is working, just not in complex nested bitmask maths. So, the example I gave in my previous post should work in 3.0.8.1 just as well. Here's MyCo about the question to avoid it completely:

You can still use it, but not in complex statements

[ChrisHooker]

The modulo implementation seems to work without issues in this instance (attached). (Using 3.0.8.1)

Tula, I meant that since KG is needing a counter, he may encounter this limit issue. I don't know much about assembler, so have no idea if the limit applies to it as well.

[Spogg]

@ tulamide
My clash with the modulo issue was in a relatively simple DSP code. I deleted it and found another way so I don’t have that code now.
I didn’t know about the Ruby speed issue though.

My worry about “downgrading” is all the stuff I’ve made and found so far.

It would be great if there was a list of issues with 3.08.1, all in one place for reference…

Cheers

Spogg