DSP Robotics Support

Hey all,

Im trying to design a copy and paste function which saves data (knobs, switches ect) to a virtual clipboard, then pastes.

Basically I have a prog that has 3 filter modules and I want to be able to copy the settings from one and paste it to another.

My original plan was to create an array with all the data I want to copy (from 1st filter). Then when you click a button (copy) it sends the array to a "clipboard" module which holds it for 5 seconds.During which you click a paste button on another filter module. It then tells the clipboard to paste here, which it sends the array and the 2nd filter module handles the parsing and connects it to the relevant knobs ect.

Is there a better way of doing this? I have a feeling my schematic is going to get WAY too complicated that way.
Can I do it with a hacked preset manager module?

Anyone got any tips?

Thanks!

you could write the values to be copied to a text file then read from it...

Yeah I thought of that but I dont want to be creating files. . .

Ive got it working now with wireless links and sending arrays.


Ill put a link up when I get the chance if anyone wants it

Hi there,
I've implemented this idea in a couple of my old SynthMaker designs, and your suggestion of using an internal array was pretty much what I ended up with. The biggest hassle is having to make custom versions of the controls that include the copy/paste feature.

The trouble with using the preset manager is that it has no easy way to move a value from one parameter to another. It's not impossible, but as far as I can see, you'd have to save a temporary preset file, edit the contents of the file, and reload. That might be simpler in FlowStone, as Ruby has some pretty nifty file and text parsing features - but it still wouldn't be trivial, and would involve some quite serious surgery to the preset manager to automate the saving and loading of temporary preset files.

Doing it internally, you don't really need that many components - but you do need to modify any controls so that they can have their value set independent of the GUI. Here's a very simple example...

The important parts are...
- The "preset" module of the knobs have been 'hacked' so that there is an input for setting the value from outside.
- The little 'copy/paste' module inside each knob - mostly this just uses sample&hold primitives to trigger when a value should be moved. But there's also a little module in there called 'sender' - this allows many different sources to all send to the same destination. Normally they'd all get added together, but the 'sender' uses a bit of trigger logic so that only the most recently triggered value gets through, and all the others gt ignored (really set to zero).
- The 'clipboard' itself. Nothing much to it - just a sample and hold that hangs on the the most recently copied value. I used wireless connectors to join it to the controls, but normal links would wok just as well. For copy/paste of multiple parameters, an array isn't strictly needed - I just use a load of these little S&H primitives, and re-name the wireless links as required, so that each parameter effectively has it's own mini-clipboard.

Hope that gives you some ideas for your own designs - just post again if there's anything that I didn't make clear enough.

EDIT) Ah, just saw your other post - would be interesting to see how you solved it.
BTW, I have also done something similar using text files as sal suggests. It's a bit more complicated, but can be handy if you want cut/paste to work between different instances of the program.

Drnkhobo wrote:Yeah I thought of that but I dont want to be creating files. . .

Ive got it working now with wireless links and sending arrays.


Ill put a link up when I get the chance if anyone wants it

if you don't need text files, then you can do it the trouggloudite way and you can add a timer if the clipboard must be cleared after 5 seconds.

Hey guys,

Thanks for the help, ive actually made a simple clipboard schematic here:



Basically it contains a clipboard module which deals with the copy and paste.
Then the module where you want to do the copy and paste settings.

All ive done is create a 8 val array and when you click the c button it sends a copy signal to the clipboard.
The clipboard holds the array for 5 seconds in which time you click a p button on another module and it sends the array via a selector depending on the module you clicked p from.

Hope this helps!

Also Trog, Here is a pic of how I checked for the INF problem.
Ignore the mess of the stuff out the red circle but see how I get a false when I get a INF. . .

On this topic, how would one go about connecting the values to be pasted to their corresponding knobs ect?

Also when the paste happens, can you have the knobs turn to their new pasted values. . . .
Hmmm. . .

Drnkhobo wrote:On this topic, how would one go about connecting the values to be pasted to their corresponding knobs ect?
Also when the paste happens, can you have the knobs turn to their new pasted values. . .

Take another look at my previous download - that shows the basic idea of modifying the controls. It will be a little bit different for each type of control, but they usually all have a VST preset somewhere, and just add the float switch right in front of it - then you know for sure that the preset value got updated as well as the knob value.

I a bit dubious of the 'timed clipboard' in your example, it could potentially have some problems with users that are in a hurry. If several buttons are pressed during the 5s timer, the clipboard will receive some very confusing data at the places where the strings and arrays get joined together. So if the user wants to do lots of cutting and pasting, they'll have to count five seconds between each one.
That's why I use the 'sender' module method in my designs - it mean that the clipboard always contains the most recent copy, no matter how nuts folks go with the controls. It could maybe be adapted to use arrays, like yours, but I have never really bothered, as it's no less complex due to all the array builders and extractors that are needed.

Not to sure wth the INF example - the idea is right, to eliminate values that go out of range, but without knowing what comes before and after, it's hard to say if it is the best solution - often you can get away with using min and max modules to do this using a few less components (but not always!).

One bit of advice though - if you need to peek at a value to see what it's doing, don't connect the little green boxes in line - connect the bits together directly, then put the readout to one side. That's because they suck up a bit of CPU power, calculating the text to display etc., so they're best deleted when you're done with them. It's a lot easier to delete them if you don't have to re-build the links afterwards...

Thanks Trog!

Ill have another root around your schematic
Could you explain the sender module. I see it sends a trigger to a S&H with the current values.
Then Into the sender module, which . . .

And yeah, the INF prob is still a problem. It was just a way of getting around it really. Still not a fix
I think im going to try fiddle around with the DSP code a bit but im used to Ruby's clean lazy syntax lol!

Drnkhobo wrote:Then Into the sender module, which . . .

Ah yes, it's a tricksy little module - if you are into nice clean Ruby, the way that green 'triggers' work might leave you scratching your head for a bit.

The essence is that every green pathway doesn't just carry values - but also triggers - ALL of them, not just the ones called 'triggers'. And nothing happens in 'green land' without a trigger!

When the value comes in, it sets the switch to that value - but there's a trigger blocker after the switchl, so the value doesn't get to the output just yet.
However, the next link from the input goes to the little module that just extracts the trigger that came bundled with the new value- and that goes in two directions (little tick marks on the links tell you which way it goes first)...
- First the trigger goes to the module's output - this causes the output to spring into life, grab the value from the switch, and pass it on to the rest of the schematic.
- Second, it goes to the other switch input. As there's no number there, it forces the switch to zero - but the trigger blocker again stops it from passing to the output - yet! (the proper value that got sent isn't affected because it has already been delivered to the clipboard).
There may be lots of other senders - all connected to the same 'clipboard' module, and at this point they must all be added together. Whenever a sender' puts out a value, this adding up gets done - when this happens, any of those 'zero' values that didn't get sent out before (because of the blockers) finally get read, and because they are all zero, don't affect the addition - leaving only the current value to be seen.

So, as you see,, triggers are a bit more complex that they first seem - but you can think of them as being a little like making a method call in Ruby - they force something to be done with a value. And don't be fooled by the way you can make 'parallel' links, splitting and joining signals - there's no parallel processing going on, so the ordering of the links takes the place of putting statement line by line in code to get stuff in sequence. It might look like a psychedelic spider's web, but it really is programming, with all the same concepts as other languages (just prettier to look at!).

I've been working with these triggers in the older software, SynthMaker, for a good few years now - and it has changed very little in FlowStone (but FS has loads of other cool goodies, of course!). Over that time, I made quite a few demo's and tutorials about 'green' triggers (and other things). Eventually, i hope to port these over to this forum - but I want to wait until I have FS3, so that I'm not just confusing people with out of date stuff!!

The INF thing can be tricky because really you need to find out exactly where that value is coming from (i.e. could be buried inside some code somewhere). Usually it will be a divide by zero - but sometimes you get zero's coming from odd places that you wouldn't expect. As your gizmo looks to be an RMS of some kind, I'd suspect maybe a log() function - there's no correct log value for zero or negative numbers (though sometimes you get zero out of them, which is not mathematically correct, but simpler to deal with in code), so possibly you need to put an ABS or MAX somewhere.