In-place value edit

Tom7777 · 24 Mar 2005

Thanks stefancrs, awsome as usual 🙂

Kitchen Sink · 24 Mar 2005

Wow, great hack. 🙂 Isn't that what Synthedit is all about, hacking? There are so many ways to do things. That component is excellent for making user interfaces.

I'd still like module parameter editing as an integrated Synthmaker feature, like I described in this thread. It would be silly to use these in-place versions for all module parameters, if the edits aren't meant to be shown to the user. (15 unnecessary components for each value + GUI connections)

stefan · 24 Mar 2005

Unnecessary? Where do one draw the line, is all the connections within a user built LFO unnecessary because the LFO could be a standard component instead? Etc 🙂

I don't think this is a hack. I think it's a nice way to use inputs that you could just set to a value or connect something as a value instead, it's up to the module developer instead of "locked" by default behaviour of SM. Maybe you don't want all parameters to have a in place value edit, maybe you don't want _any_ to have it. And so forth.

Kitchen Sink · 24 Mar 2005

I meant "hack" in a good way. Using Synthmaker just gives me a tickling hacking feeling. 🙂

The components are unnecessary, because they don't need to be compiled in the final product, and a lot of GUI connections are needed. If I have, say, 200 internal parameter values inside a synth, that would generate 3000 components.

If Synthmaker allowed editing values connected to module inputs from outside the module, I don't think that would lock anything. It could be disabled in preferences, i.e. if you absolutely want to open the module each time you want to see or modify a parameter.

Why would you not want some value to have an in-place editor... do you mean you want to be able to click on it without invoking the editor?

stefan · 24 Mar 2005

Ok 🙂 Yeah, well, me too, apart from that we use different words for it 🙂

For instance the float data component has a float input. I'd prefer if that input did not have a in-place editor. same goes for all values you want specific editing abilities for really. How would 200 internal input value connectors result in 3000 components? Also, the gui codes parts does only run if they get a message. How would this be solved internally in SM without solving it basicly in the same way as I did? And how would they be removed from "the final product" ?

And, again, if you place the values outside of the module, you don't need gui connectors for them. So for 200 value inputs you'd just need 200 "inplace value" modules. Which only affect the synths perfomance when you actually use the inplace editor. Granted, you could also just use the float data component if you don't want the inplace editor to appear on the modules gui 🙂

Maybe malc has some thoughts about this as well 🙂 I think it works best the way it is right now, but obviously there are different opinions about that 🙂

malc · 24 Mar 2005

Kitchen Sink, can I first say that although I seem to be disagreeing with you on things at the moment (the toolbox and filter bar issue being the exception) I totally agree with your motives. You want the user experience to be as smooth as possible and so do I, which is great 😀

I'm just not totally convinced about your idea (raised here). One thing I'm struggling with is why you'd want to do this. Whenever I put a String, Float or Int into a schematic it's usually as a constant. So I don't find myself going in and out of modules continually changing things.

If there is a parameter that I do want to change often, it'll end up getting linked to a control in a Module GUI somewhere down the line.

So at the moment I see the situation you're trying to address as more of an edge case. Maybe you have some particular example in mind that would help illustrate your point?

I do like the flavour of what you're saying though from a design persepctive, I just don't think it's necessary and is not worth the sacrifice of the input label system that currently exists.

Out of interest, if the point is to avoid going in and out of a module to set parameters, does your suggestion fully alleviate this problem? Let's say that I have a module that does exactly what you're suggesting. If I want to edit parameters I do it in-place. What if I want to edit parameters in a module that is inside it? I still need to go inside and out again.

Anyway it's always good to have someone challenging the design and for that you have my thanks 🙂

Kitchen Sink · 24 Mar 2005

Malc, you said so many things I won't try to quote them. But those are all things I have been thinking.

- About parameters being constants: one aspect of identifying a module's function is its parameters. Like, "multiply input by 2 and divide by 5". Those can be inside the multiplier-divider module, but then I'd have to name the module "mul 2 div 5" or something, in addition to having both numbers as values inside the module. Or I could make it parametric and connect two values, but that would clutter the surroundings of the module.

- The label system wouldn't have to be sacrificed. Why not show both the label and the value? Or show values only when hovering over the module, or when it's selected.

- What if you want to edit parameters that are inside the module and not exposed as inputs of the outer module, then you will have to open the module I guess. I'm not trying to completely eliminate mouse clicks from the face of the earth... 😀 But the internal parameters could of course be exposed by the outer module by making direct input-output connections to the internal module's parameters - if the parameters are so elemental to the outer module. (if you've ever studied Microsoft's COM, this may sound familiar...)

I'm suggesting all this partly because I'm a long-time Delphi developer, and I'm used to viewing the properties of a component in a name - value property inspector. In Delphi, you can change all data types in the inspector, not just primitive types like integers and strings.

Anyway, if you decide this is not needed now, it shouldn't be too difficult to add it in a later version, because this is all really just "GUI sugar" that doesn't affect the compiled code.

stefan · 24 Mar 2005

Somehow I'm still not convinced 🙂. I think I need to see a good example of when this would be used in a good way. The small example above with a module doing a "mul 2 div 5" is a lousy example imo. Such a module is very specific in its task and it would be better to just insert a small code module for such things. When it comes to modules where it's purpose heavily depends on it's input values (in this case, 2.0 and 5.0) I'd never dream of adding those to my toolbox.

unkargherth · 11 May 2005

Well. I really not agree with "all around editable connectors". but, in some aspects, a "property editor" on a module would be helpful, very helpful

Example: A float input whose plug isn't connected produces a 0 value. Why? A zero value could be a perfectly legal and useful value, so we need a certain way to specify the diference between an unconnected input and a connected input whose value is zero

A Property Editor would be nice to do it. simply rightclick on the module, select property editor and establish the DEFAULT and the UNCONNECTED values for it. Not disturbing, No backward uncompatible changes,etc

It could be said that this should be an application default. Zero for unconnected and fullstop. I disagree. There are a lot of cases Wich default should be 1 and unconnected 0, or default 0.5 and unconnected any value, including 0.5

Also bound checking could be included in this property Editor if needed

Don't know if my comments belong exactly to this thread but the property editor gave me the clue....