Bus and wireless connection cost (YASQ)

For general discussion related FlowStone
Post Reply
deraudrl
Posts: 239
Joined: Thu Nov 28, 2019 9:12 pm
Location: SoCal

Bus and wireless connection cost (YASQ)

Post by deraudrl »

Are wireless connections and buses "free" in the sense of not using measurable amounts of additional CPU? (By "additional" I mean relative to the tangled mess of lines that would otherwise represent the same connections.)
I keep a pair of oven mitts next to my computer so I don't get a concussion from slapping my forehead while I'm reading the responses to my questions.
MichaelBenjamin
Posts: 275
Joined: Tue Jul 13, 2010 1:32 pm

Re: Bus and wireless connection cost (YASQ)

Post by MichaelBenjamin »

.
Last edited by MichaelBenjamin on Mon Sep 21, 2020 10:28 am, edited 1 time in total.
User avatar
Spogg
Posts: 3368
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England
Contact:

Re: Bus and wireless connection cost (YASQ)

Post by Spogg »

My belief is that what you see on the screen in the edit environment is merely a representation of the compiled code. So, following that through, I would expect there to be no additional CPU if a connection is represented as wireless or wired.

These days I make much use of Wireless because it makes the schematic a bit nicer to look at. I still like to show the audio routing as wired though, because I find it easier to follow.

Others may have more insight into this question though...

Cheers

Spogg
User avatar
trogluddite
Posts: 1730
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: Bus and wireless connection cost (YASQ)

Post by trogluddite »

MB and Spogg are correct, wireless and busses are just a different way to describe the net-list that's then used to "compile" the processing model. Once compiled, there's no additional CPU cost, though as MB points out, greater complexity and string label lookups add to the overhead of re-compiling with each routing change.

Note that selector and multiplexer components work in this fashion too. Whenever they are switched, they modify the net-list and invoke a re-compilation, which can occasionally lead to undesirable audio artefacts. Likewise when switching is done by changing bus create/extract labels. The upside of this is that (stream, at least) parts of the schematic which have no route to an output or display are omitted from the compiled processing model, so consume no CPU at all (hence downstream selection is recommended over upstream multiplexing).
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Post Reply