From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Shifrin ·
Hi,
Check out this schematic :-
Get it here :- [url]http://www.btinternet.com/~sephid/sm/FineBug.osm]FineBug.osm[/url]
I'm trying to make a custom dragable area which does the following, dragging vertical as normal, draggin horizontal fine tunes (this has been talked about before but not done correctly yet afaik).
The way I thought to finally solve this was to have a seperate DragX and DragY and choose which one I want to use (based on whether I am dragging vertically/horizontally).
The section of the schematic outlined in red works out whether I am dragging vertically or horizontally, outputting a 1 for vertical and a 0 for horizontal. No problems there afaik. Try it out and watch the int output go from 0..1.
The section in blue has the multiplexer with the two drag components. If I hard-code the input to the multiplexor to '0' I get my fine tune, if I hard code it to '1' I get normal coarse behaviour. Incedentally which ever drag component is being used updates the value of the other!
So, I thought it should be simple to take the output from the red section and connect it as the input to the multiplexor (shown by the magenta line).
But it just won't work seems to only update when I drag vertically 🙁 And it also seems to cause another bug which, although I can't give an exact way to reproduce it, happens regularly with this schematic - and has also been mentioned before :-
The float/int components 'freeze' and no longer let me click on them and edit their values!!!
So, any chance you could check this out?! It is very odd, I am sure it should, in theory, work like a charm.
Cheers,
Shif.
unkargherth ·
Well , although i have no exact clue there are two things you can try
First. Instead of multiplexing mouse area, how about multiplexing it's output, There could be an ( undetected) problem with multiplexer and mouse area
Second, jorge or malc ( can't remember) told me when i was developing The Definitive Knob, that you can't have DRAGX and DRAGY for same mouse area. Try to do the same using dragxy module
Anyway, Now we have is key pressed i think SHIFT + dragy is easier for finetunning, but this is only my opinion
Shifrin ·
Hi,
Thanks for your input Unk 🙂
unkargherth wrote: First. Instead of multiplexing mouse area, how about multiplexing it's output, There could be an ( undetected) problem with multiplexer and mouse area
I'll give that a whirl - if I understand you right!
unkargherth wrote: Second, jorge or malc ( can't remember) told me when i was developing The Definitive Knob, that you can't have DRAGX and DRAGY for same mouse area. Try to do the same using dragxy module
Ok, will give that a go too (although I think I tried that too using a slightly different method and it didn't work either). I've used this method to solve the concentric knob problem, i.e. overlapping mouse areas with a multiplexot - but as you said there is a known issue with this for DrgX and DrgY. Thanks for pointing it out 🙂
unkargherth wrote: Anyway, Now we have is key pressed i think SHIFT + dragy is easier for finetunning, but this is only my opinion
Indeed! I just wanted to do it for the sake of it, hate giving up on a problem when I think I *should* be able to solve it 😉
Shif.
infuzion ·
If you connect an out for each of the Float Switches, you'll see that they always have the same values. But somehow the output on the Float Greater tends to fliip to 1 from 0. interesting...
jorge ·
well, I'm not sure if this is the cause of the problems but it's worth to know it just in case:
I've been sorting many of the Green components, they should work a lot better in the latest version 0.9.3q. The file format related with them has changed so in some cases you might have to save with the latest and load again to notice the new behaviour.
The Green components havent been a priority until now, they should become much more reliable with the latest and next few releases.
Shifrin ·
Thanks for the info guys, TBH the part of the schematic that seems to flip from 0..1 for horz..vert is a bit of magic I arrived at! I tried doing it a different and more logical way! Anyhow, seems there is something odd going on here, I'll leave it for now 😉
Shif.
jorge ·
Shifrin, I just had a look at your schematic. I thought of a way to fix it but got stuck with the editing floats bug, I think we need to fix that first.
The dragX and dragY keep focus. When you start a drag on a dragX and then switch to a dragY while dragging, the dragX still has focus, that's why it doesnt work.
I think the way around it is to use the dragXY and use a selector on the x and y float values it outputs. I'll try it after we fix the float edit bug.
jorge ·
Actually, I just noticed, a way around the editing float bug is to use Tab and shift-Tab until you get to the float data component you want to edit and then just type the new value.
jorge ·
Here's what I came up with:
not quite right yet but it might help.
I think the functionality you want should be helped by extra outputs in the dragX, dragY and dragXY like floats for state on click down and even a boolean output on the dragXY component telling you if the drag started horizontal or vertical.
Shifrin ·
Thanks for looking at this jorge! I'll have a bit of a play with the DragXY (and your schematic) after what you've said about the DragX/DragY keeping focus etc.
Cheers!
Shif.
jorge ·
We found a bit more about your Fine Bug. The problem is that when you start a drag the dragX is getting focus but while dragging the selector changes the flow of the View messages to the dragY causing dragY to get the release focus and dragX to keep it when it shouldnt. When you're at that stage with dragX having focus is when you'd notice the float data editing bug.
I think we need to revisit the design of the drag acumulate components and make them more user friendly. Until then it should be ok if you use only one at a time rather than combining them.
Tom7777 ·
I have noticed some bugs with the GUI modules when used in certain ways, i guess it might be a good idea to check through them sometime.
Shifrin ·
jorge wrote: I think we need to revisit the design of the drag acumulate components and make them more user friendly. Until then it should be ok if you use only one at a time rather than combining them.
Sounds good to me jorge, again thanks for looking over this for me 🙂
Shif.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker