beta 0.9 f general comments

malc · 27 Nov 2004

Thanks cbit - good to hear from you.

A certain amount of praise is always nice for motivation but criticism is much more helpful when developing the kind of product we want SM to be 😉

I take your point about the coordinate system. We'll have another think about this.

You can already reset the zoom: select Reset from the View menu or press the HOME key. Maybe the menu item could have a better name? Note that this also resets the scroll position as well.

I'll pass to Jorge re. the stepping, he'll be better placed to look at that.

The online documentation is something we put on hold a while ago but we certainly haven't forgotton about it. Thanks for the link, we'll check it out.

jorge · 28 Nov 2004

cbit wrote: I still think its a shame the coordinate system doesn't automatically correspond to pixels (rather than grid squares), that would be much simpler to understand i think, and im guessing it'd fit most peoples needs. (what do other poeple think?) Personally i don't think i'd use zoom functionality in the GUIs i'd be creating with synthmaker.

The zooming mechanism is used to make the task of editing schematics easier. Are you saying that you'd prefer SM not to have zooming at all? I think what you're saying is that you wouldnt use zoom inside a VSTi after exporting it. In my opinion, working with pixels is a separate thing more related with the way the primitive components work, something to be added to the existing functionality probably through the form of new pixel based primitives. I think we should find a way to work with pixels that fits well with the existing system. The editing of the front panel still needs some work to be more user friendly like for example allowing controls to be positioned with the mouse.

cbit wrote: I noticed a 'stepping' sound in the example schematic when a parameter know is adjusted while it plays, could we have a 'smoothing' or interpolation module/component to avoid this kind of thing?

Yeah, definitely, that was in the old version of SM, we need to include in the new one.

Thanks for your suggestion about the wiki. The main problem with lack of documentation is that the framework has been changing quite a lot. We need to let it settle a bit. Once it does, I think writing documentation is not going to be a problem.

malc · 28 Nov 2004

I think what you're saying is that you wouldnt use zoom inside a VSTi after exporting it.

That's what I'm reading too. I think it's a fair point.

As Jorge said, everything in SynthMaker is scalable to allow zooming of the schematic and make editing easier. However the mistake we might be making at the moment is forcing users to worry about this when really the software should take care of all that for them.

The MGUI essentially allows you to do two things: 1. create something for a front panel and 2. create a symbol for your modules. In the first case you're thinking in pixels and in the second case you're thinking in grid steps.

I'd be prepared to bet that the MGUI will be used far more for front panel stuff. We should therefore make the GUI components work in pixels and then find a way to convert back to grid steps when we need to zoom or do something else with the framework. But this should be done behind the scenes so that users don't need to worry about it.

To cover the other case I think we should have a GridStep to Pixel component.

There are a few implementation issues with all this Jorge so I'll need to speak to you about them but I think it's all very possible and should make the coordinate system much easier to understand.

cbit · 28 Nov 2004

thanks for your replies.

yes, i was talking about zooming in the exported vst(i) guis.. i wasn't clear enough but you rfigured it out 🙂

Zooming in the authoring environment is handy feature, i wouldnt want to do without that. Thanks for letting me know about the zoom reset menu item malc. i was imagining that there might be a small 'reset' icon placed in the center of the draggable zoom bar.. or that by double clicking the bar, the zoom would reset to 100% (that was one of the first things i tried). Maybe this is a minor issue i'm worrying about .. but the graphical nav system would feel more 'complete' for me with some 'quick zoom reset' mechanism like this. what do you think?

I'm pleased to read your replies about the coordinate subject. I really don't mind if synthmaker keeps it's grid step basis, as long as it's easy to work with pixel coords if the user prefers (i agree with what you mentioned malc, that maybe the 'default' could be pixel coords, and there could be mechanisms to convert to gridsteps if necessary.. or something). Pixels seem like it'd a more intuitive and practical distance unit to me. Anything for a simple life 🙂

thanks!

malc · 28 Nov 2004

Hey cbit, it's the details that make the difference so don't ever worry about highlighting so called minor issues. I like your idea about the zoom control - leave it with me.

antialias · 15 Jan 2005

personally, i like the idea of grid-based as opposed to pixel-based locating. when one thinks of creating GUI elements, it seem natural for them to want to adhere to a coordinate system that is relative, rather than absolute.

i guess what i mean is that, while you may always want the cutoff knob to be two knobs to the left of the filt_lfo knob, you won't always want it to be 278 pixels to the left of filt_lfo. my first computer was an apple ][e, on which you'd probably want to space the knobs by less than fifteen pixels.

my point is the advantage of relative over absolute when one considers things on a larger scale.

-anti

cbit · 15 Jan 2005

isn't antialias' preference for relative positioning also compatible with an 'actual pixels' approach though?

malc · 15 Jan 2005

I think two are compatible cbit, which is good news for all 🙂

That said, I'm not sure what it is that you are getting at antialias so please feel free to correct me if I've misinterpreted.

What I think you're worried about is that if you specify a fixed number of pixels then when you zoom the distance in pixels will be preserved. let me reassure you that this won't be the case. If you zoom then the distance will be scaled accordingly - distances will always be relative to the zoom scale.

The real issue is how to specify distances. At the moment we do this in grid squares, where at the default zoom one grid square = 8 pixels. So a distance of 4 squares is equivalent to 32 pixels.

But we could easily have it that distances are specified in pixels relative to the default zoom. That would mean that 32 pixels would show as 4 grid squares at default zoom, but at twice zoom it would show as 64 pixels. At twice zoom 64 pixels would still be 4 grid squares so the relative spacing is maintained.

Whatever happens the system will use relative positioning, the question is what units to use to specify distances. Of course we can easly have a convertor to go between the two, but we have to decide which would be the most sensible to use as the default.

I have finally got round to looking at these issues so it's great that there's some more discussion. Let me know if this makes sense.

antialias · 16 Jan 2005

hah, i think "absolute vs relative" wasn't what i was trying to say... posting while drunk i was. i think what i meant to say was that abstract units are easier to work with than the actual physical units. just seems that way in my mind- smaller numbers and easy scalability.

-anti

malc · 16 Jan 2005

SynthMaker turns you to drink? Oh no, not a great advert for us 😉

On a more serious note:

antialias wrote: abstract units are easier to work with than the actual physical units. just seems that way in my mind- smaller numbers and easy scalability

That's absoultely fine and it's the key reason for the discussion: some people prefer gridsteps, others prefer pixels. We can easily have both (you can do this at the moment by creating a module to convert between the two systems).

Maybe one solution could be to allow you to declare your preference in advance by means of an option in the settings. Schematic files would record this preference and conversions would be applied if the file is opened using a copy where the other system is prefered.

How does that sound?

malc · 24 Jan 2005

We've been thinking about this alot over the last few days and have come to the conclusion that my earlier suggestion may be too complicated. Our favoured solution is to maintain grid squares as the base units for GUI components but provide convertors for working in pixels.

We've nearly finished implementing an interactive system that complements the existing system quite nicely. This will mean that you don't have to explicitly position GUI elements by typing in coordinates. This means that you'll be dealing with the pixels vs grid squares issue less often.