Check If Input Is Connected?

[Perfect Human Interface]

Hi everyone. I'm hoping this forum is fairly active. I'm new to Flowstone and while I've been really happy with the amount I've been able to accomplish in a short period of time, I have had an awful lot of questions that I've been struggling to find answers to.

Anyways, is there any way to check whether an input is connected (has something connected to it) and return a boolean value? From what I understand about Flowstone I'm guessing there isn't... but this is one of those things where I wonder how people can live without.

Basically right now I'm trying to modify my knob objects so that they could accept an input value and simply pass it through rather than the knob's own output value. Should be very easy if I could just check if an input is connected. Otherwise, I don't even know how this would be possible.

Thanks in advance.

[Nubeat7]

hello & welcome here, i`m not really understanding what you mean with "check if input is connected" - you need to wire it to connect it to somewhere, so you see it anyway, you also could connect readouts to check if there is some dataflow...

for setting a knob from outside you can look at this:

http://www.dsprobotics.com/support/viewtopic.php?f=3&t=641&start=30

just make an input and use a lastswitch before the set-in of the knob module and you can send data into the knob..

[Perfect Human Interface]

i`m not really understanding what you mean with "check if input is connected"

Not check for my sake, I mean output a boolean, whether an input has a wire connected to it or not. Now that I think of it, the "selector" component has this kind of functionality built-in, but it's hard-coded (and yeah I just tried to see if I could abuse it for this purpose, but it won't update the index automatically).

for setting a knob from outside you can look at this:

http://www.dsprobotics.com/support/viewtopic.php?f=3&t=641&start=30

just make an input and use a lastswitch before the set-in of the knob module and you can send data into the knob..

Is it necessary to use that knob you made rather that what I'm using?

I wasn't familiar with "lastswitch" until now, so thank you. Seems like it would be perfect except it doesn't accept a stream input (*grumble grumble connectortypes*).

Actually I may not need a stream at all...


Edit: It looks like that little component will be close enough to what I needed. Thank you very much.
Edit 2: Still need a solution for stream inputs though, for e.g. LFO's and such.

(Sorry for all the edits; I don't know when to shut up.)

[Nubeat7]

no you dont need to use this knob i just wanted to show you how to use the lastswitch for setting the value from somewhereelse... you can do this also with other knobs...
maybe you should read this, to get a better view on the concept of the different datatypes and connector types and what they are for..
http://www.synthmaker.co.uk/dokuwiki/do ... green_data

[nix]

With the stream last,
if you'd like, post a schematic of the particular application
u need.
Stream switching is doable,
streams are also reasonably versatile.

Like NuBeat mentioned, readouts are great for analysis,
there is pretty much no way to tell where a link terminates other than chase it.
You can press tab on wireless sends to see where they are recieved.
Hope u continue to enjoy FS 8D

[trogluddite]

Hi there, welcome to the forum,

Very interesting question...

.. but this is one of those things where I wonder how people can live without.

I've been active on the forum and over at SynthMaker (the 'grandaddy of FS) for many years, and I've honestly never heard this question asked before! But my first love was tinkering with electronics, where it's rather useful to know - what happens if I cut the green wire?!

Firstly, yes you're right, there is no way to test if an input is connected to anything. All inputs have default values (zero,false, empty string etc,) - but a connected input could quite validly be sending in one of those values, so that wouldn't help much.
But apart from some fairly obscure things where you're trying to save CPU load on audio processing, I've never come across anything where there was any need to know whether a link was present. (I'll come back to streams in a moment).

The answer has to come from the way that a schematic is arranged then...

To take the simplest case. If having a connection or not is a choice that you offer to the end user in your final design, the solution is simple. Somewhere in your design is a GUI control that decides whether to engage that feature or not - so the on/off value is available somewhere from the relevant control.

In the case of 'green' parts, it's probably best not to think of the links as like wires in an "electric circuit", but rather as channels for sending messages along. All green parts just sit there doing nothing until a message is received containing a new value. You've probably come across the green 'trigger' data type already - the secret is that all green data types have triggers inside them too.
Nubeat's example shows this well - the 'last switch' simply responds to whichever of its two inputs are sending new values - the hidden triggers let it know when to change value, and which input the value came from.
Once you start thinking in terms of triggered messages, it becomes simple to make a module behave in different ways depending on where a value came from. As an unconnected input is never going to receive any triggers, you can be sure that it will have no influence on the module's behaviour.
To get at the triggers inside any green value is simple - just plug it into a trigger input; the value itself will be ignored, and any value changes will behave just as if you connected a real 'trigger' link.
By way of an example, here's a little schematic showing how to make a boolean that tells you which one of two knobs you are moving...

Hidden Triggers.fsm

(126.49 KiB) Downloaded 1016 times

You might find this old (unfinished!!) tutorial from the SM site useful -all of the green stuff is pretty much the same in FS, and the example schematics should load in FS just fine.

Streams are trickier - they are running all the time at sample rate, so there isn't a 'message' system in quite the same way. Because of the high speed of the data, they are designed to be as simple as possible, otherwise they would chew through CPU power.
Again it comes down to design.
A disconnected stream input always sees a steady stream of zeros. And in most cases, this is actually just fine - if you turned an LFO depth control right down, then zero is what it would output anyway . For a well designed module, disconnecting modulation inputs should have no effect on the output.
There are a few rare cases where you do have to explicitly check for silence coming in on an audio input. Just checking for zero might not be reliable because audio signals tend to cross the zero point rather a lot! The only solution there is with some kind of proper audio level detector - similar to what's used in the GUI level meters.

Hope you enjoy your time with FS. Although FS is quite new software, there's plenty of other SynthMaker old-timers here - so just pop back any time to pick our brains when you get stuck.

[Perfect Human Interface]

I've been active on the forum and over at SynthMaker (the 'grandaddy of FS) for many years, and I've honestly never heard this question asked before! But my first love was tinkering with electronics, where it's rather useful to know - what happens if I cut the green wire?!

I'm sure at least a few people on here come from a programming background... I'm not a "programmer" but I took some classes in high school and have a basic understanding. I'm sure any programmer could relate to the need for "ifs" in any conceivable circumstance.

If having a connection or not is a choice that you offer to the end user in your final design, the solution is simple.

Nope! The end user doesn't see it; it's for development.

It's rather simple. I'm building modules with knobs (and other controls) that control important parameters. Now let's say I want to use this module inside of something bigger, but I want those controls to be wired to and controlled by something else in the schematic rather than the knobs. I could go through the process of removing the knobs, creating the necessary inputs and rewiring everything (and it's not unusual for my knobs to wire out to seven inputs) in every case. But if I could just build the option to accept an input and bypass the actual knob into all my knob modules, then everything I build wouldn't have this trouble of messy rewiring anymore.

The "lastswitch" is pretty close to perfect for this, as I can just wire something else into it and then as long as I don't touch the knob again (it's disabled easily enough) it will just ignore it. But as I mentioned, since it doesn't accept stream input, I can't control these parameters with things like LFO's. This only works for passing data from other knobs and such through the knobs (which may be useful but it's not quite enough).

[Nubeat7]

oh yes, you really should read the triggertutorial from trogg, it opened my eyes and everything about "green" was much clearer then!

you also can use streamdata to control a knob , you need to read out the streamdata with a freq you can choose using the mono to float primitive and a ticker to read the streamsignal with every tick (trigger) and you get the actual value of the stream.

[Perfect Human Interface]

you also can use streamdata to control a knob , you need to read out the streamdata with a freq you can choose using the mono to float primitive and a ticker to read the streamsignal with every tick (trigger) and you get the actual value of the stream.

So I can use "mono to float" to convert streamdata to greendata at a particular sampling frequency... now that is useful. I'm guessing it will inflate CPU at sampling rate though.

Almost humorously I imagine this still won't work with "lastswitch" because it will be updating constantly. That is unless lastswitch works by performing a check to see if an input signal is different than before rather than just looking for some kind of update.

Okay... so trying this out just now I've gotten some odd behavior using the custom ticker wired to "mono to float," with an audio stream on the input and a mono readout on the output. What sounds like underruns from SM's output (my host sequencer is reporting low CPU usage and no underruns) and crashes, especially at lower custom values.

Edit: Tick100 seems to work fine. It's nowhere near sampling rate but I think that will be more than enough for LFO's. But it doesn't have that convenient on/off switch. "Ticker - custom" is completely broken, even at very reasonable values.

[trogluddite]

I'm sure any programmer could relate to the need for "ifs" in any conceivable circumstance

Yes, but in FS your cchematic is the program itself - your proposed 'if' statement would be equivalent to something like "If this program has a line 50..." or "if this program uses the "print" command..."
In programming that is referred to as "reflection" - the ability not just to check the values of variables, but also the ability for the program to find out information about its own programming code. In some languages, including Ruby, this is possible to a degree; but in most it is not - an "if" statement can only refer to a variable value, and referring to a non-existent variable usually results in a error.
No doubt, if FS did have the ability to reflect in that way, we could find many good uses for it, but we don't have access to the 'engine' inside to that degree. I certainly was not intending to pass judgement on your request, I can see how it would have some advantages - just a case of being pragmatic about the tools we have available.

It's just the nature of the beast, I'm afraid - FS has been designed to try and make a modular construction kit output relatively efficient exports, and if every input had extra code for checking the linking status, that would only add to the CPU load and memory needs of the schematic; for a feature which would be redundant for the vast majority of inputs.
Without a doubt, some things could be done to minimise the 'spaghetti twirling' - I like your suggestions on your other thread for moving multiple links, for example. I have suggested many times in the past that output connectors are particularly awkward in that respect, and I'm all in favour of new GUI features to make development faster (and don't even get me started on the lack of proper de-bugging tools!).

But there comes a point in any development environment where the comfort of the developer takes second place to the efficiency of the final product - though whether we think the FS developers have that balance right is a matter of taste, naturally.