Pleeze help with mis-behaving knob!

[k brown]

I love the look of these knobs, and just built a major project entirely around them before remembering that their default behavior is, well de-faulty. They are set up for Cntrl/Click default, and they dutifully go to the default setting they are given, but when the left mouse button is released they snap back to wherever they were before, rather than remaining at the default setting. I've tried everything I can think of - even replacing their greens default modules with ones from other knobs, but nothing works. I'm sure someone who understands the greens inner workings of knobs better than I will look inside and say "of course it snaps back, the framitz is connected to whosy instead of whatsy!"

Bad Knob.fsm

(104.2 KiB) Downloaded 988 times

P.S. - seems I'm once again able to post attachments; I was getting an 'over the limit' warning. If someone got that re-set for me, thank you, thank you!

[tulamide]

Of course it snaps back, the framitz is connected to whosy instead of whatsy!

For real though, there was a trigger missing. I hope it works now ok for you. There is still an issue when you use control to snap to default, then release control to start moving the knob (all of that without releasing the mouse button). As soon as it moves, it will start at its last position again, not from the set default position. That can't be changed without a complete schematic change, as value changes are only registered with the schematic and the preset system, when the mouse button is released.

So for any normal situation (control-click to set default, then release mouse button), it works just fine now.

[k brown]

Thanks so much for having a look. I should have known it was more likely something missing rather than connected wrong.

This is a huge help as I completely finished a huge project using nothing but these knobs, before remembering their default problem. When I used them some months ago, it was in an effect plugin, where default knob positions are not that necessary, but in a synth it's very much expected and helpful.

Thanks again 't'!

Edit: Turns out I can't open the schematic, either by dbl clic or 'open with'. I get a mssg. about not having SSE support. Could you take a screenshot of where you put the missing trigger? - or is it not that simple?

[deraudrl]

Edit: Turns out I can't open the schematic, either by dbl clic or 'open with'. I get a mssg. about not having SSE support. Could you take a screenshot of where you put the missing trigger? - or is it not that simple?

I'm getting a "created with newer version" error (I'm using 3.0.6)...I'll try it upstairs on the current alpha when I get a chance.

[tulamide]

I'm so sorry, Kevin!

Sometimes it happens that I start working by double clicking the fsm, but unfortunately the alpha is registered to start with that. And I didn't think about it. Will correct it!

EDIT: Done! See my last post, it now offers the 3.0.6 version.

[k brown]

Terrific - got it, thanks again. Boy that was simple!

[wlangfor@uoguelph.ca]

I've noticed sometimes knobs can go south and save old default values. So that you need to manually trigger the sample and hold inside the nested modules. Simple when you see it, frustrating to find though.

[deraudrl]

I get a mssg. about not having SSE support.

Upon further review, as they say in the NFL...

I'm a bit surprised this error message would even still exist in the alpha version: are there any current (as in less than 15 years old) Windows-capable CPUs that don't have SSE support? I suspect Kevin's machine has SSE support, unless the alpha is requiring the latest and greatest revision.

[tulamide]

You're mixing things up. It's not the alpha that reports it, but his synthmaker version, when he tries to open a FS4 alpha schematic. So, the message simply means ... nothing.

But, of course it can come to missing SSE support errors. There are different revisions of SSE. As far as I know, FS 3 sticks to SSE 2.0, but that doesn't mean FS4 might not use features of newer SSE revisions, say SSE 4.2 (as far as I know it is currently not using them, it is just an example here)

[trogluddite]

I suspect that, as tulamide hints at, the error message is a legacy string dating back to the days when non-SSE2 machines might have still been around, and which is now essentially meaningless - to be read as "unidentified doodad broke the unidentifiable wotsit".

I always have similar thoughts when I dip into the application options. In all my time using SM/FS, I don't recall anyone ever having a problem which was fixed by ticking the "Save SSE compatibility" box in 'Advanced options'. Just as well really, as it's clear as mud what the option actually does, and I'm pretty sure there's not a lot it could ever have done about an SSE2 opcode hard-coded into an assembly primitive.