From the original SynthMaker forum (2004–2014), with its members’ names and dates.
fabb ·
The multiplexer sends the input value to the new destination when the index changes. This is not always wanted, so this is a feature request to add a boolean input to the multiplexer letting switch off this behaviour. So it just sends a trigger out when the input VALUE changes and not the index.
If you care what I'd like to use the multiplexer for: I build a dispatcher which gets a string in and decides where to put it out (multiplex) deciding by the first character. When I do it with a multiplexer now, I would have to put a string sampler component to every output of the multplexer. Otherwise when the multiplexer switches, the old (wrong) string would get sent to the new destination and then the new string would get sent to the new destination. Not quite elegant.
infuzion ·
Workaround, by me:
But you don't have to use the right-most Floats, you can connect them to any float-in, as long as you send a trigger-passthrough from the item that feeds the Multiplex.
fabb ·
jo! good old trigger blocker... the problem is, i work with strings! i get in a string, split it in two and depending on the first half, i route the second half to the right output. i'll post a screenshot sometime later.
fabb ·
hm, but when i convert the string into an integer first it could work with a bit redesign...
thanks,
fabb
fabb ·
infuzion wrote: Workaround, by me:
But you don't have to use the right-most Floats, you can connect them to any float-in, as long as you send a trigger-passthrough from the item that feeds the Multiplex.
Problem is that the "old" target gets set to 0 cause it also receives the trigger and asks for the value which is 0 cause it isn't connected (the multiplexer disconnected it).
Is it likely that such feature requests get implemented?
electrogear ·
fabb wrote: Is it likely that such feature requests get implemented?
Don't quote me on this, but I'd say 99 times out of 100, they don't. I've seen many features suggested that I thought were really needed, but they still haven't been implemented. I can see why though - the developers would rather work on bug squashing and efficiency I guess, and address these other improvements later, or in the version 2(??) of their software.
I'm at the point now where I'd be glad to purchase a version 2 just to get an improved program (events wise, and CPU wise). I think the updates are coming too slowly at the moment, and recent updates have brought very little in the way of improvements and features, other than the iFFT, which isn't any use for me at the moment until I get to grips with the more basic foundations of DSP...
Don't get me wrong I'm not knocking Outsim. It's up to them of course how fast or slow they set the pace, and if they only have one or two guys working on it then you can't expect too much...
fabb ·
I see. Have you got an idea for a workaround to this?
infuzion ·
fabb wrote: I see. Have you got an idea for a workaround to this?
When I was a kid, we were so poor we had to make our own jigsaw puzzles.
fabb ·
oooh, poor kid 🙂
i've got it already like this. i wanted to switch over to the visually less stressing multiplex alternative...
fabb ·
edit: but interesting how you moved the simple directly connected components over one another, actually looks good!
infuzion ·
fabb wrote: edit: but interesting how you moved the simple directly connected components over one another, actually looks good!
It is actually ripped from my "Sample & Hold On Change"; the downstream won't trigger if the data hasn't changed.
fabb ·
ok, i had now another point where i needed this option for the selector. oh, the feature-greedyness... it really would be useful, you know.
oddson ·
Long before your time, and early on in mine, there was a related debate:
[old link]
I think a better suggestion than complicating the multiplexer more would be to add sister components to the float trigger blocker for the other data types. This would allow you to achieve the result you're looking for relatively easily without complicating a main-stay component unnecessarily.
I would assume trigger blockers that pass other data types would be a fairly easy addition.
Regarding the 'what it's for...', I'm a recent convert to the merits of the custom parser. If you want to share the details of what you're trying to achieve I think I could help you build something more elegant to get the job done.
(Believe the hype -- the search feature is fixed!)
fabb ·
but using trigger blockers as infuzion offered above just doesn't work. the problem is that when the input value changes, ALL not connected multiplex-outputs are set to 0! this is even worse!
parser component.... veeeery interesting! will look into this sometime!
this is the thing i wanna do (on several occasions in my schematic):
(why can't i upload schematics here?)
http://stud3.tuwien.ac.at/~e0725639/decodepads.osm
oddson ·
So...
1) you want the outputs to remain stable (not reset to zero when not selected)
2) you want the selected output to trigger only when the value is different than it's previous value
Correct?
Here's an image from an old posting (for integers in the present example):
This passes only new values (along with their trigger). So if you make something like this (with String 'equals' and 'sample and hold') you should be able to prevent triggering when you your multiplexer changes index but the value at that index is unchanged.
If you're saying you only want the multiplexer to process the string when it changes then the same trick can be used on the left-hand side to limit processing to when the input string is changed.
N.B. the trigger order is important here.
infuzion ·
oddson wrote: Here's an image from an old posting (for integers in the present example):
yaaa, that is from my "Sample & Hold on Change", isn't it? That's why I used it in my encrypted (I didn't want to make it too easy, have to make them work & learn) picture above, though your version is far easier to understand 😇
fabb ·
oddson wrote: So...
1) you want the outputs to remain stable (not reset to zero when not selected)
yes
oddson wrote: 2) you want the selected output to trigger only when the value is different than it's previous value
no! it should always trigger. but thanks for the idea, i'm sure i can use it elsewhere.
ie for the encoder, it always sends the same value for each step in one direction. there of course the same value happens several times and should always trigger.
when you look up at a picture of a previous post of me, you'll see that i already have got a working version without a multiplexer. but this way isn't really satisfying as it's overly complicated compared to the multiplex variant i posted in my last posting. and in the version without a multiplexer, many more (useless) calculations have to be done! for each possibility, a comparison is made. with a multiplexer, the input routes itself to the right destination, only one calculation.
like this the multiplexer makes only sense for stream data in my opinion.
oddson ·
fabb wrote: The multiplexer sends the input value to the new destination when the index changes. This is not always wanted, so this is a feature request to add a boolean input to the multiplexer letting switch off this behaviour. So it just sends a trigger out when the input VALUE changes and not the index...
This statement seems to contradict your most recent:
fabb wrote:
oddson wrote: you want the selected output to trigger only when the value is different than it's previous value
no! it should always trigger.
Here's what I thought you were after:
fabb ·
oddson wrote:
fabb wrote: The multiplexer sends the input value to the new destination when the index changes. This is not always wanted, so this is a feature request to add a boolean input to the multiplexer letting switch off this behaviour. So it just sends a trigger out when the input VALUE changes and not the index...
This statement seems to contradict your most recent:
fabb wrote:
oddson wrote: you want the selected output to trigger only when the value is different than it's previous value
no! it should always trigger.
not really. when the input changes, it is split into the routing (index) part and the value part. when the order is that i have connected the index part to the index input of the multiplexer first and then the value part to the value of he multiplexer second and the input changes, the following happens: multiplexer first switches to the new destination which causes the component connected to the new destination to ask for a new value. this is the bad behaviour. this lets the component connected to the new destination get the old value. then the new value causes a trigger on its own and sets the destination to the new correct value. this makes the output first getting set to a wrong (old) value and then to the right one.
if you connect the index part and the value part the other way around, the same problem happens, but the old destination gets the new value first which is no better.
oddson wrote: Here's what I thought you were after:
ok, i'm relly to tired now to look into this. tomorrow is also a day... probably what i wrote up there is unreadable... goodnight 🙂
oddson ·
Ok... it's a trigger sequencing issue.
I think you're causing your own problem with the sample and hold right before the multiplexer. It's holding the old value until the final trigger from the input integer fires after the multiplexer has switched to the new index value. If you take it out it seems to work without pushing the old value. The only downside is there are two triggers fired (if the index is changed) but the value seems to be the same (the new value) with both triggers.
My version from the earlier post cuts out the extra trigger and also avoids downstream processing if there is no change.
fabb ·
the sample and hold can't be left away. otherwise when a switch of the first hex char between 4 and another value occurs, this causes an additional trigger. in the worst case this makes 3 triggers. you'll see this when you first press the upper trigger button and then the lowerest one.
http://stud3.tuwien.ac.at/~e0725639/decodepadsOdd2even.osm
i'm currently thinking about another workaround.
why can you upload files in this forum and i can't? in the other forums it works fine for me. hm.
fabb ·
HA! got it. i told you i could use your idea of the "trigger only on real change" 🙂
this should be adaptable for my other use cases, let's have a look.
so this routes a value to its destination and also triggers if the input data didn't change but occurred a second time. and no more false triggers!
fabb wrote: so this routes a value to its destination and also triggers if the input data didn't change but occurred a second time. and no more false triggers!
thanks for your help oddson+infuzion!
You're welcome!
A resent value is resent though, is that your intended behavior?
fabb ·
yes! for once for the encoder which sends the same message for each direction. and the second thing is the type routing. the first character is the destination (button, pad, knob...) and the rest is data (or pad number + value etc). so when only the first character changes and by coincidence the data part is the same, but means something different (pad number + velocity as the first character identifies as pad message instead of button number + value as the previous first character identified as button message), the data would be eaten up but it shouldn't. ok this sentence was too long and complicated... but whatever, it works fine! some more cleanups and i'll upload the first version of my padkontrol communication module!
infuzion ·
fabb wrote: yes!...I'll upload the first version of my padkontrol communication module!
Cool, I'm looking forward to it. 🙂
fabb ·
i uploaded my first "official" version to the examples forum!
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker