DSP Robotics Support

If you look inside my SIM-GUZHENG you’ll see what I did to make use of mono4 (pack-unpack) for the sound generators ... You’ll also see that I got 4 formant filters for the price of 1!

Gonna try'n'muster up some courage to look inside some of your stuff to see if I understand something... Like looking at MV's ASMs?... a mystery.

Well. If you see a bright flash of light and count the loud bang to ~900miles away. You'll know it's my head imploding, and the compressive shockwave just hit your local area

A while back I posted a little tutorial on SSE usage, you may find it entertaining:
viewtopic.php?f=4&t=6372&p=235015

A while back I posted a little tutorial on SSE usage, you may find it entertaining:
viewtopic.php?f=4&t=6372&p=235015

Wow! you are busy...

I don't use much blue but I can probably use those ASM:ed packing modules of yours as they are.

And that fast power!... splendid stuff. Tried the toolbox one out on something a while back... can't remember for what. But I do remember it ate CPU almost as bad in that context... as the buses in my synth before I started sorting them out, separating them I think there's even more to be done regarding the buses.
My synth still gobbles CPU, but looking at all your stuff there seems to be hope for alot of improvements.

That's nice since I wan't to throw in more stuff into it If I can.
If... I can keep the current CPU usage but with the extra stuff planned. I would be happy

No high hop()es for me understanding ASM, math and the the more technical stuff, but I'm going to try and go through it when I'm in the right frame of mind... something might stick

Buses buses buses...

Trying to simplify and hopefully receive some fractions of performance gains. I'm in the process of reducing packing and unpacking prims.

Below is a big questionmark though. I'm still unsure... Does the bus add same-named values together at junction points... or does it only add them together at unpacking? It would make zero programmatical sense that they would add encapsulated values together (at the bus level) from my logic standpoint.



I think I'll have to do a controlled test to make sure how they behave...

I know variables for example usually are assigned cryptic names inside when code is compiled... so I suspect buses themselves also are kept separate at low level.

Really?...



Well aaaa-all'righty then.

Buses really need a companion prim called "bunching" that does "only" that for using as transport up and down hierachies... I think Maybe I'm an idiot and have missed some vital logic here. Maybe a big button in FS. Wouldn't be suprised typical me in that case.
This behaviour doesn't rule out of course the two buses aren't still separate until unpacked Simple analogy "bus + bus = bus[[2],[4]]"

So question is then:
Overhead cost of adding "busses as busses" vs "unpacking a lot of busses at destination (8 unpacks at each destination) and adding there". Seems just as crazy as adding buses.

I also guess there might be a difference in bus size/length. And a really interesting thing is how green float and streams coexist inside buses regarding updates and priorities... well... keeping data integrity as someone wrote.

I make a little test.
(Was also asking myself if adding stream outside of a code was fast as inside.)

We could see the code generated with the analyzer.
It seams the same with link add, asm or buses.
But the micro cpu analyser have a little more for the buses. (not so much comparing to bigger code)

Comparing the text code, with buses there's 2 more line at the end. A read and write.

Cool test Tepeix

That's interresting! I wonder why the ASM addition is so much faster than the regular addition...? Or rather why regular addition "is slower".

Does CPU throttling skew the result of this test somehow? As it looks to be using correlation between samplerate and a time...? I have no idea how the analysers work under the hood...

I can confirm somewhat that I actually notice a fractional improvement after consolidating my buses, reducing the total amount of packing/unpacking. But it's hardly noticeable... I maybe gained a single voice at around 23 played notes... before my synth starts acting up on my current PC i'm testing on. It shouldn't act up at all, but I think there's some DSP filter in it that performs badly.

I never used buses, so I cannot comment on that. But before you start optimizing I‘d recommend some profiling so you know the pain points. PM me if you do not want to disclose your schematic.

I never used buses, so I cannot comment on that. But before you start optimizing I‘d recommend some profiling so you know the pain points. PM me if you do not want to disclose your schematic.

Well, we'll see I'm holding this one tight to the body... But I really appreciate any enthusiasm you have for it.
Sharing any part of it, even If I would, and privately, would be to embarrasing taking into account your level of knowledge, Spoggs, tulamides or the rest Seriously You know that bucket-toy with bricks?
At this point... I'm the little boy trying to fit the cube into the wedge shaped hole

The most stupid parts are the menus and their selector-logic. I'm planning to move them into "Ruby only" in time. Now they are immense green schematics.

But despite any of that... I'm not even finished with the synths basic structure yet...

At the moment I'm just cleaning up (buses etc) and eye:ing the performance as I do, so there's no extreme drops in performance.



It just got slightly closer to goal and a bit more versatile as we speak. A few minutes, and just 4 selectors and 2 multipliers. That's a damn bargain
But more than an hour to fix all the UI layout aspects for it probably

--> Then onto an auxiliary oscillator (sub oscillator). Which wasn't planned really. Half way into this, I realised that not having a decoupled suboscillator outside the ROMplery part was too restrictive. The aux oscillator is going to cost me CPU

--> More LFO waveforms. Don't know when "to much is to much" but I really feel the urge to add exponential- and- sample & hold-versions of atleast some. That shouldn't cost much cpu.

--> >Then it's time for the mini LFOs... These will be a nightmare. And maybe that's the breaking point when I need some serious optimizing. After that there will only be new (and or) changes to current osc-modules.

Not taking into account my own sh*tty schematics Three things I know are a somewhat suboptimal and do have some direct performance impact are the filters I use.

--> The chebychev ASM (yours I think? edit: asm by Dozius?) I used in FS 3.08 didn't work in FS 3.09 last I tried, so I reverted to DSP version and used that instead.
I'm going to try again, it might just be a compile issue that's solved by copy paste into new ASM box?

--> The unknown filter, probably some 303-ish 15 or 18db variant is DSP only. Either it's a relic from an old .OSM I had laying aroung or it's something found here. Maybe from the synthmaker greatest hits thread...

--> Toolbox solid state variable is of course DSP only. I don't know what to do about that either...