DSPplug tick100

[trogluddite]

I was referring to My new testing method rather than AronB's. I agree that Aron B's is sound but maybe a little off

I should say that I didn't mean to sound disparaging about AronB's module, nor even your test method, per se - it is as good as it could be within the bounds of what is possible in FS, and I know of no other way that's significantly better.

The point of asking my riddles was this: Testing apparatus constructed within FS is subject to the same imperfections as any other part of a schematic, so you have to keep in mind the margins of error. For example, one might try timing the interval between ticks by feeding them to some kind of stream module; maybe hoping to get a "resolution" of one-sample - but that would be incredibly deceptive because streams are calculated in blocks equivalent to audio buffers, so there would be a huge error margin from passing events between the "green" CPU thread and the "blue" CPU thread. Similar applies when mixing green with Ruby, or when using Ruby Frames. In addition, the test apparatus will always consume CPU power, so there will be an "observer effect" whenever CPU load affects the results.

In general, I would advise against relying too much on testing the CPU/timing performance any component in isolation, whether green, Ruby, or stream (though unit-testing of functionality should be encouraged!). On a multi-tasking, multi-core PC, there are so many ways in which CPU scheduling and memory pipelines can affect performance that testing within a real-world scenario is far more useful in practice. Anything that isn't slaved to its own independent crystal clock (e.g.. audio samples) should be regarded as having suspect timing, IMHO, and that includes our "virtual test-bench".

[wlangfor@uoguelph.ca]

I am so often humbled by audio. Just the other day I was able to make bass without distortion and it sounded so beautiful. in fact it sounds perfect but statistically it's ruined. However, volume wise - it's still at par?

I'd realized that bass is always going over 0, and limiting it, relying on a low grade of crossover wasn't enough for the specs. But there i was, realizing that bass without distortion sounds so much better, realizing that I'd be laughed at for believing it better. And the strange part is the volume is perfect.

Here were My test results re-mixing sauce by tentaction:

Before (after one pass of -1 dBFS Max):
L: 0.22 dBFS
R: 0.21 dBFS

After (Two passes and Brickwall)
L: -0.45 dBFS
R: -0.13 dBFS

So, as you can see; over all there's no damage but the bass is still less thick, and less muddy. The right after would have been higher, but I ran out of test time.

[wlangfor@uoguelph.ca]

Tick Talk, I wanna Rock, I wanna Roll, or maybe ... a donut hole. Every time I use the 'ticker' my 'puter' acts like it's full of 'pickers' that eat my CPU and snicker, if Zebras were horses I ride one too. Well, they are sorta. Uhh, I might just 'bend' a sample and hold or timer or somethin' because this 'tickety-trigger' thingy between the green and the blue is … I'm certain we all agree. Bangin' on the Bongos like a Sympho-Chimpanzee. Doesn't matter … this particular 'prim' of any flavor acts like …. a mechanical hand egg beater lookin' for a piece of action with an Air Force Osprey. If it Works … don't fix it. well …. as far as I can tell none of 'em do … yet, perfect or near it. So, don't let your real 'ticker' get in a 'wedgey' FSer's … lettuce, turnip and appease to all just kinda keep lookin' for the proverbial Eureka! Here's an example we all agree on. Who was that man that reversed biased an FET Transistor in order to find a really neat 'gate/trigger' for the old analog synth ADSR? Or even weirdlier is the 9-12VDC upside down bias 12AX7A Tuber Overdrive … maybe there was a power 'brownout' and it made his amp sing like a bird. Sometimes mistakes happen … then all of a sudden you 'tweak it' haphazardly in a completely different direction and VOILA. Every cup is half full … even if there's only the tiny 'starting pebble' in it. Then somebody comes along and takes the pebble out and throws it away … and puts a drop of honey in. Next guy adds a drop of vinegar, next dude, an olive, then some yo-you drops some spam in it with tomato juice and celery to fill the cup before there's to many cooks. Everybody really digs it so they make a whole big pot of stew out of the same ingredients.
It's called, "FlowStone Stew." Before that it was 'Synthmaker.'

Like my Compozatron 3 ...
http://www.dsprobotics.com/support/view ... 31#p111431

Now it doesn't eat 100,000% CPU … all the time … I started 'feature de-creeping' it …

See how I stuck my foot in the door … ha hee hee ho!

P.S. Anybody into SynthEdit … I ran outta stuff to make with it and so cranked up my FS. Bought it and had it on the spare ext. hard drive for over a year. Then pulled it outta the 'cobwebs' and … whhoW.

The dude in my Avatar is really me … recent 'jam' … I'll be '69 years young' June 19th, 2020!

Thanks for these raps. I used to do the same when I was younger. I checked out your compozatron. Happy 69'th btw. Sorry, I've been so busy that I'm catching up So, as a response I made a rap about this whole tick post called tick beef. It's a rough and It needs work but here's the video:

Youtube Video: Tick beef

[Spogg]

Nice work Robert!

Cheers

Spogg

[wlangfor@uoguelph.ca]

Nice work Robert!

Cheers

Spogg

Thanks, it's a fun hobby. I used oversampling on the vocals though because I was in a rush. I usually prefer rap vocals processed with linear filters, but it's a good rough.

[wlangfor@uoguelph.ca]

I just wanted to add, this is really only a technique which you would wish to employ for something that's required to be accurate. I've now tested this algorithm and realized that the three empty modules to spread the ticks are hard on the x64 version for some reason, and by just using the tick100 prim with the ruby tick and the sample and hold is enough.

So, with that said, keep in mind this is good for averaging where you have a meter and an LU meter etc where you want it to be time accurate. But if just an anlayzer, consider using only the primitives.

[MichaelBenjamin]

.

[Spogg]

Just as a side note, I checked the Ruby ticker with ASIO on and it showed about 1.5% CPU on my system (core i7).
So I made a stripped down version with no inputs and it ticked, but still used 1.5% CPU. The Tick 100 prim didn’t register any CPU in the same situation.

For me that’s a deal breaker for using a Ruby-based ticker.

Cheers

Spogg

[tulamide]

Just as a side note, I checked the Ruby ticker with ASIO on and it showed about 1.5% CPU on my system (core i7).
So I made a stripped down version with no inputs and it ticked, but still used 1.5% CPU. The Tick 100 prim didn’t register any CPU in the same situation.

For me that’s a deal breaker for using a Ruby-based ticker.

Cheers

Spogg

You're comparing apples and bananas here. If you're fine with a ticker that runs anywhere between 20 to 60 Hz, without any reliability, use the tick 100 prim. But don't think that it doesn't cost CPU. It just doesn't register any load, because the system is doing the work. It is outsourced!

[pshannon]

I will admit I am a little ignorant related to the tick issue with FS.
If the tick is so flawed, isn't everything built around the timing in FS and should our designs be flawed too? Is this tick prim based on the internal 18.2 times per second? I remember back in the earlier days, we had to sync with this for the purpose of the variances in CPU speed sync to animation and sound.

I have a link below to an old pc mag from 1984 talking about freq, timing and general sound in the old qbasic. I remember this back article as a kid.
https://books.google.com/books?id=ZhoP0 ... &q&f=false