DSPplug tick100

[pwesynthmaker]

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 ...
viewtopic.php?f=3&t=37382&p=111431#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!

[Spogg]

I'll have what he's having

[pwesynthmaker]

Spogg, Trogg, I am Peeweesynth ('pwesynth') the Wog Blogger. IMO … Ruby is fantastic … like HTML to C+ to C# and so forth. Yet, we all know it's 'trait' is that of the advancement of RAM. Windows 3.0 was 6 Floppy Disks with about I Trillionth the Random Access Memory. A whole almost a whoppin' 100 Megabyte Hard Drive and it ran at about 100 MHz. Even so, some if it's Ford-like 'Model A' features were lost in the mad dash to try to pump pure light through cold-hard Silicon at break-neck frequencies that will probably, eventually make a teeny, weeny black hole that causes the beginend of the 'cosmic reverse-big bang.' I began working on an actual Piezoelectric Crystal Virtual Vacuum Valve/Tube Holographic Display Projector for Notebook Computers about 20 years ago and recycle binned it. But, in all reality it is the only method feasible to actually be able to safely produce near light-speed binary electronic data transceivance. It would process at about 10 KHz and emit completely harmless full spectrum rainbow imaging from the infrared to ultraviolet frequency range. Now, if I can just get the Gorilla Tape to hold it together with a little super glue my Starship Boobyprize will fly.

SO … I wrote this tangentblog stuff … and then downloaded the greeny/divider ticker thingy and it got me ponderosarizing … could we cosine and tangent the custom 100 trig Ruby to pump out three separate 'ticks' at those precise angular voltage chords 30, 60 , 90 Isosceleswise. Think about it. With that and 'greater than or' and 'less than or' script in the cosine/tangent rms functions and leave the natural sine as flyin' V stat … bang goes the three stooges at one stable output. Maybe? Plus ... 'false' it off at say … 3ms max [errr … (PI)e-3 actually that would match a pythagorean debug]. Since it reality everything now is +-5V Boolean Square Wave it might just be a way to doorhinge it. The three bears 'hysteresis' voltage tick offbeat blocker. The cosine and tangent 'sibling' voltage rms levels would still trigger. Sorta, like my 'Tunetron' is set up only more advanced in short to the point Ruby. The way he hooked that up so simple in the 3-piece suit … like … anybody wanna help slingshot the pebble into green eggs and ham.

[MichaelBenjamin]

.

[MichaelBenjamin]

.

[trogluddite]

if you use tickers fed to green related stuff which inserts into the audio path - weird stuff will happen

Indeed - and for DSPplug tick100, the two/three at once "parallel" triggers can make a serious problem...

simultaneous triggers.fsm

(97.33 KiB) Downloaded 865 times

In the schematic (NB: must turn on audio!), the scopes show how amount of trigger count change at blue sample - we should expect every trigger = count rises by one. This is true for bottom scope (normal tick100). However, on upper scope (DSPplug version), you can see that the count increase by 2 or 3 when trig dividers send parallel triggers. There is no spread across time - all 2 or 3 triggers arrive on exact the same sample (because of green/blue CPU thread prioritys, probably 1st sample of a new buffer).

Suggested application is for frequency scope - but for this, the extra triggers is no use at all. The 2 or 3 triggers are processed so quick that they happen in-between audio buffer refresh - all parallel triggers wil read (and maybe ReDraw) exact same audio data (if reading audio), or only final value change out of 3 affects outgoing audio (if used as green -> blue/white parameter). Imagine, say, toggle goes on and then off again in same in-between audio buffers - blue/white does not see any change happen at all.

So cheating trigger count by sendin parallel triggers is unwise - as MB says, can have nasty side-effect for blue/white that is hard to debug (was a huge mystery when first time I remember it discovered!) Trigger timing is very wobbly always, but 2 or 3 triggers very near simultaenous makes the worst possible "clock jitter".

[Spogg]

I think there’s 2 points here.

One is that the DSPplug thing does supply the amount of ticks per second that it boasts.

The second point is what is a good application for such a thing, since the ticks are very unevenly spaced.

When I first saw it I thought it was interesting, but I tried to think of what I could use it for and was unable to come up with anything, precisely because of the uneven gapping.

Cheers

Spogg

[wlangfor@uoguelph.ca]

Well, the whole point of this frankly was to avoid ruby overloading. it of courseoverloads at 100hz, so why try to run a tick at 100hz right? It will always overload. And it will always overload if it's affecting something you see?

As long as ruby is not attached to something there is none, so it could be used as a timer to run a gate to allow a c+ trigger through. Works right?

And it's pretty close, but yeah; it can be improved. Maybe it's better to use a max trigger system like I've seen used will try that too and I'll make a visual aid to show how accurate this system is that will display realtime.

But it's like I said, Tulamide you're acting like this is a debate in debate class where there's a prize and I'd like it if this idea could be improved. We're people stuck with a product that needs fixes, not arguments.

[ChrisHooker]

the ticks are very unevenly spaced.

It's not just that they are unevenly spaced, it's that they are exactly as unevenly spaced as a Tick100 prim, because that's what they are driven off of. Tick Dividers merely let out the Nth tick they are fed. When combined with the original, that only overlaps existing ticks - it does nothing to change the timing, therefor the additional ticks generated are useless... but they will increase CPU.

Additionally, the "flaw" in the green timing system isn't just in generating the ticks, it's also when FS READS the ticks as well. So long as you stay in green, the actual spacing between non-simultaneous ticks is minimized at this inherent limit, regardless of how many ticks you try to feed within that spacing.
Compare a ruby-generated Tick100, and it will show the same thing. You may get SOME additionally jittery triggers showing randomly, but it is still nothing at an even spacing, nor predictable, aside from the main ticks that line up with the system clock, just like any other green-generated trigger source.

Green is not intended for more accuracy than this. If you need faster, more reliable triggering for audio processing, it should done be in blue. You can code so that a "1" is generated every Nth sample (or whenever a variable meets a requirement), and a "0" is generated for all samples outside that requirement, then have your code process the audio when the "1" is present.

Wlangfor, you claimed your method is better and more precise, when in fact it is not. Tulamide is just trying to ensure that everyone understands what is going on in the schematic / FS in general, and to not allow misinformation. I personally thank him for this, and hope he keeps doing so. Any rudeness might be because of HOW you present your work, always claiming it is better. Perhaps if King Oz were a bit more humble, he wouldn't continue to receive such criticism.

[wlangfor@uoguelph.ca]

the ticks are very unevenly spaced.

It's not just that they are unevenly spaced, it's that they are exactly as unevenly spaced as a Tick100 prim, because that's what they are driven off of. Tick Dividers merely let out the Nth tick they are fed. When combined with the original, that only overlaps existing ticks - it does nothing to change the timing, therefor the additional ticks generated are useless... but they will increase CPU.

Additionally, the "flaw" in the green timing system isn't just in generating the ticks, it's also when FS READS the ticks as well. So long as you stay in green, the actual spacing between non-simultaneous ticks is minimized at this inherent limit, regardless of how many ticks you try to feed within that spacing.
Compare a ruby-generated Tick100, and it will show the same thing. You may get SOME additionally jittery triggers showing randomly, but it is still nothing at an even spacing, nor predictable, aside from the main ticks that line up with the system clock, just like any other green-generated trigger source.

Green is not intended for more accuracy than this. If you need faster, more reliable triggering for audio processing, it should done be in blue. You can code so that a "1" is generated every Nth sample (or whenever a variable meets a requirement), and a "0" is generated for all samples outside that requirement, then have your code process the audio when the "1" is present.

Wlangfor, you claimed your method is better and more precise, when in fact it is not. Tulamide is just trying to ensure that everyone understands what is going on in the schematic / FS in general, and to not allow misinformation. I personally thank him for this, and hope he keeps doing so. Any rudeness might be because of HOW you present your work, always claiming it is better. Perhaps if King Oz were a bit more humble, he wouldn't continue to receive such criticism.

lol, well I could probably throw down a better track but whatever. Being humble frankly doesn't make equalizers function, doesn't avoid the 2% CPU bulge.

Being humble is going to cause a customer to complain about there being such a bulge of an extra 2% usage of the CPU caused by Ruby overloading when it goes over 100hz and its code is affecting something while it is tweaking over 100hz. Being humble wouldn't have made a better equalizer. Being humble would not have resulted in both phonics and myself making a working, better model of EQ that's getting easier and easier to re-create.

Being humble wouldn't have resulted in you posting the blue idea, which is a better idea in most cases.

Being humble in most cases hurts innovation. You either put yourself out there to get something done or go home and you never innovate, it's a plain and simple thing. People put themselves out there by being rude, so why not go that extra step and try to also be innovative. Frankly I find rudeness to be so less creative than actually trying to innovate a solution.

It's why it's useless to listen to people enforcing a status quo when the status quo doesn't work. So, that's My raspberry to being humble. It's like how useless it is to bow to youlean and waves and the k-metering solution, they only register -20 LU when in fact the pink noise sample suggests it should register at -23 LU.

Flowstone forum link
http://dsprobotics.com/support/viewtopic.php?f=3&t=46955&p=144220#p144220

ebu link
https://tech.ebu.ch/publications/ebu_loudness_test_set

If I hadn't tested and used the code by MV, Myco and The OM then that increased accuracy would have never happened. The world frankly has been held hostage by those who have stayed humble. The EBU recommendations for double accuracy and oversampling have been around since 2016 and who was innovative enough to figure out how they reached that meter result?

Flowstone forum link
http://dsprobotics.com/support/viewtopic.php?f=3&t=46955&p=144220#p144220

There are thousands of people who've had in-accurate metering that they've relied on that's totally in effective. See here. Should they be humble too? Or could they sue Youlean? How humble would that make them?

You tube video #1


You tube video #2


Should I have been humble?
stuff being humble Bro and stuff nonsense in a care package for someone else.

Here's a song called be humble: