Discussion:
GUI Design Project
(too old to reply)
thor
2011-01-16 22:34:01 UTC
Permalink
Hello colliders

As many are aware of, SuperCollider is now being implemented in a new
GUI framework called Qt ( http://qt.nokia.com/ ). There was a thread
on the look of that GUI : http://www.listarc.bham.ac.uk/lists/sc-dev/msg19324.html
and we subsequently set up a dedicated project for this on the Wiki
page here: http://supercollider.sourceforge.net/wiki/index.php/GUI_Design_project

We now finally have a submitted design that is realistic and fit for
discussion on the lists.

http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition

The design of these GUI elements will be implemented in Qt and
therefore giving SC a unique look that is still minimal and neutral.
The question of native versus SC style look is something we might want
to discuss. Also it would be good if people would submit their wish
list for new widgets (or new features to existing widgets) to be
implemented.

Note that this is a sketch that will be further refined when written
in Qt and one that is put forth for the sake of discussion, not as the
final design.

So opinions, suggestions, wish list items, etc. welcome. Also, if
someone has alternative designs or wants to have a go at refining this
current design, please go ahead.

thor


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Miguel Negrao
2011-01-16 23:07:11 UTC
Permalink
Hi

I really like this design, it’s very clean, pleases the eyes without too much eye candy. I think it will make SC look quite amazing !

Any idea on how long it will take to implement ?

best regards,
Miguel
Post by thor
Hello colliders
As many are aware of, SuperCollider is now being implemented in a new GUI framework called Qt ( http://qt.nokia.com/ ). There was a thread on the look of that GUI : http://www.listarc.bham.ac.uk/lists/sc-dev/msg19324.html and we subsequently set up a dedicated project for this on the Wiki page here: http://supercollider.sourceforge.net/wiki/index.php/GUI_Design_project
We now finally have a submitted design that is realistic and fit for discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
The design of these GUI elements will be implemented in Qt and therefore giving SC a unique look that is still minimal and neutral. The question of native versus SC style look is something we might want to discuss. Also it would be good if people would submit their wish list for new widgets (or new features to existing widgets) to be implemented.
Note that this is a sketch that will be further refined when written in Qt and one that is put forth for the sake of discussion, not as the final design.
So opinions, suggestions, wish list items, etc. welcome. Also, if someone has alternative designs or wants to have a go at refining this current design, please go ahead.
thor
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
Scott Carver
2011-01-17 00:44:00 UTC
Permalink
This is absolutely excellent. It looks, to me, like a good balance of customizability - enough that you can tweak things in a functional and aesthetic way, but it doesn't give you enough rope to hang yourself (unless you want to hang yourself).

Couple questions / comments:

- I'd love to see the mockup with a dark versus light background. The palette is neutral enough that a dark background would be a potentially easy switch, and I definitely appreciate having the option of both.

- With multi-sliders whose bars are narrower (i.e. 2-3 px), would we lose the handles at the top of them (I imagine we'd have to)?

- I very much appreciate the chunkiness of the buttons and grabbers. An absolute necessity if you're actually clicking around a UI at performance time.

- Tick marks / numbers on sliders? Something that has historically not really been a part of SC, but pretty important imho.

- Something I find myself continually re-implementing are sub-views, especially collapsible subviews. This is something I would love to see in the stock widget kit for SC.

- I've got some ideas for a more powerful list widget, but perhaps I'll save those for later, more specific discussions.

Totally awesome, guys. Thanks.

- Scott Carver
Post by thor
Hello colliders
As many are aware of, SuperCollider is now being implemented in a new GUI framework called Qt ( http://qt.nokia.com/ ). There was a thread on the look of that GUI : http://www.listarc.bham.ac.uk/lists/sc-dev/msg19324.html and we subsequently set up a dedicated project for this on the Wiki page here: http://supercollider.sourceforge.net/wiki/index.php/GUI_Design_project
We now finally have a submitted design that is realistic and fit for discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
The design of these GUI elements will be implemented in Qt and therefore giving SC a unique look that is still minimal and neutral. The question of native versus SC style look is something we might want to discuss. Also it would be good if people would submit their wish list for new widgets (or new features to existing widgets) to be implemented.
Note that this is a sketch that will be further refined when written in Qt and one that is put forth for the sake of discussion, not as the final design.
So opinions, suggestions, wish list items, etc. welcome. Also, if someone has alternative designs or wants to have a go at refining this current design, please go ahead.
thor
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
paul
2011-01-17 01:44:23 UTC
Permalink
Hi Thor,

I also really like this. I think it is very usable and flexible.
Great work guys!

Cheers,
Paul
Post by thor
Hello colliders
As many are aware of, SuperCollider is now being implemented in a new GUI framework called Qt ( http://qt.nokia.com/ ). There was a thread on the look of that GUI : http://www.listarc.bham.ac.uk/lists/sc-dev/msg19324.html and we subsequently set up a dedicated project for this on the Wiki page here: http://supercollider.sourceforge.net/wiki/index.php/GUI_Design_project
We now finally have a submitted design that is realistic and fit for discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
The design of these GUI elements will be implemented in Qt and therefore giving SC a unique look that is still minimal and neutral. The question of native versus SC style look is something we might want to discuss. Also it would be good if people would submit their wish list for new widgets (or new features to existing widgets) to be implemented.
Note that this is a sketch that will be further refined when written in Qt and one that is put forth for the sake of discussion, not as the final design.
So opinions, suggestions, wish list items, etc. welcome. Also, if someone has alternative designs or wants to have a go at refining this current design, please go ahead.
thor
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Nathaniel Virgo
2011-01-17 11:16:05 UTC
Permalink
I like it too. If I were going to nit-pick I'd say that the outlines of the
widgets could do with a bit more contrast. It looks good how it is, but if
one's eyesight wasn't so good then it might become a usability issue. Perhaps
the widget backgrounds could be a lighter or darker colour than the window
background, or something like that? Also, the thing marked "static text"
looks like a button. But these are very minor things.

Nathaniel
Post by thor
Hello colliders
As many are aware of, SuperCollider is now being implemented in a new GUI
framework called Qt ( http://qt.nokia.com/ ). There was a thread on the
http://www.listarc.bham.ac.uk/lists/sc-dev/msg19324.html and we
http://supercollider.sourceforge.net/wiki/index.php/GUI_Design_project
We now finally have a submitted design that is realistic and fit for
discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
The design of these GUI elements will be implemented in Qt and therefore
giving SC a unique look that is still minimal and neutral. The question of
native versus SC style look is something we might want to discuss. Also it
would be good if people would submit their wish list for new widgets (or new
features to existing widgets) to be implemented.
Note that this is a sketch that will be further refined when written in Qt
and one that is put forth for the sake of discussion, not as the final
design.
So opinions, suggestions, wish list items, etc. welcome. Also, if someone
has alternative designs or wants to have a go at refining this current
design, please go ahead.
thor
_______________________________________________
sc-dev mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
James Harkins
2011-01-17 13:07:26 UTC
Permalink
At Sun, 16 Jan 2011 22:34:01 +0000,
Post by thor
We now finally have a submitted design that is realistic and fit for
discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
It's pretty! I don't have specific criticisms.

It reminds me of one annoyance with SwingOSC, which I hope won't be replicated in supercute. IIRC in Cocoa, the menu in a pop-up menu can be wider than the pop-up menu view itself, if any of the strings in the menu is wide enough. In Swing, the menu is always the same width as the collapsed view. Sometimes you need to have a tiny box on the screen with longer strings inside. ("Well, why would you ever want to do that?" For instance, in MixerChannel, channel strips should not be too wide but the name of a target bus, listed in a pop-up menu, could easily be longer than the half a dozen characters that would fit inside the 50 pixels of the default definition.)

It just came to mind because the proposal page has a mockup of a pop-up menu where the view is wide but the strings are short. Just wondering what would happen if it's the other way around -- wishlist if nothing else.

w = Window("small menu", Rect(100, 100, 200, 120));
PopUpMenu(w, Rect(2, 2, 60, 20))
.items_(["Output bus 0", "Output bus 2", "Output bus 2"]);
w.front;

hjh


--
James Harkins /// dewdrop world
jamshark70-***@public.gmane.org
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
paul
2011-01-17 20:17:00 UTC
Permalink
Post by James Harkins
...
It reminds me of one annoyance with SwingOSC, which I hope won't be replicated in supercute. IIRC in Cocoa, the menu in a pop-up menu can be wider than the pop-up menu view itself, if any of the strings in the menu is wide enough. In Swing, the menu is always the same width as the collapsed view. Sometimes you need to have a tiny box on the screen with longer strings inside. ("Well, why would you ever want to do that?" For instance, in MixerChannel, channel strips should not be too wide but the name of a target bus, listed in a pop-up menu, could easily be longer than the half a dozen characters that would fit inside the 50 pixels of the default definition.)
It just came to mind because the proposal page has a mockup of a pop-up menu where the view is wide but the strings are short. Just wondering what would happen if it's the other way around -- wishlist if nothing else.
w = Window("small menu", Rect(100, 100, 200, 120));
PopUpMenu(w, Rect(2, 2, 60, 20))
.items_(["Output bus 0", "Output bus 2", "Output bus 2"]);
w.front;
hjh
+1

I also find this very useful to save screen space.

Cheers,
Paul



_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Scott Carver
2011-01-17 17:17:31 UTC
Permalink
There's nothing about pop-up menus in QT, at least, that necessitates them being the same width as the text+arrow component. But, design-wise, I'm not 100% sure what it would look like, so it would be good to mock it up first. I often use a super narrow pop-up menu (just the button) as a menu for doing actions (rather than selecting items from a list).

- Scott
Post by James Harkins
At Sun, 16 Jan 2011 22:34:01 +0000,
Post by thor
We now finally have a submitted design that is realistic and fit for
discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
It's pretty! I don't have specific criticisms.
It reminds me of one annoyance with SwingOSC, which I hope won't be replicated in supercute. IIRC in Cocoa, the menu in a pop-up menu can be wider than the pop-up menu view itself, if any of the strings in the menu is wide enough. In Swing, the menu is always the same width as the collapsed view. Sometimes you need to have a tiny box on the screen with longer strings inside. ("Well, why would you ever want to do that?" For instance, in MixerChannel, channel strips should not be too wide but the name of a target bus, listed in a pop-up menu, could easily be longer than the half a dozen characters that would fit inside the 50 pixels of the default definition.)
It just came to mind because the proposal page has a mockup of a pop-up menu where the view is wide but the strings are short. Just wondering what would happen if it's the other way around -- wishlist if nothing else.
w = Window("small menu", Rect(100, 100, 200, 120));
PopUpMenu(w, Rect(2, 2, 60, 20))
.items_(["Output bus 0", "Output bus 2", "Output bus 2"]);
w.front;
hjh
--
James Harkins /// dewdrop world
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
LFSaw
2011-01-18 16:10:57 UTC
Permalink
Hello,

it's nice to have that proposition. Thank you for all the effort that it took, already.
It is a quite neat design, would love to see that implemented.
In terms of (hopefully productive) critique, I'd like to mention some minor things that came to my mind when looking at these, they are of course purely subjective, but maybe someone agrees with me:

(+) I like the idea to have the ability to color-code every gui element; that might help to visually connect elements that have something in common (i.e. they are, e.g. all controllers for the same synth). I understand that this has somehow also be represented in the round knob, however, IMHO its actual design in bens proposition looks a bit out of context to the other elements. Honestly, it reminds me of a certain circus emblem, or a barber's pole [1]. This is not a problem at all, however, I think that at least in a long-term usage, this would start to annoy me a bit. But that's just my impression.
(+) I'd like to support the points concerning the background colors of both views and background, made by other commenters in this thread. I think it is rather essential to be able to change the background to a lighter/darker color, yet it should not destroy the overall look and feel. I'd love to see this sort of mockup. IMHO, there should also be a recognizable difference between a view's background color (especially in the textview) and the window's background color.
(+) Are these GUI objects scaleable? I.e. is there also a big Knob?

(+) I'd like to see log-grids accompanying the wonderful idea of a linear grid as proposed.
(+) Adding the possibility to show values (i.e. numbers) on sliders/2dsliders/knobs, etc would be great. This would need some space for the values, though.
(+) Optinal axis description (i.e. numbers) around 2D-sliders, multisliderviews and envelopeviews would be great to have.
(+) The levelmeter IMHO should have the possibility to indicate clipping

(+) I'd like to see an actual ContainerView implemented that can have a colored outline (and optionally also a descriptive text) [2]
(+) Please, some Radiobuttons.
(+) A native plot window a la plot2 would be neat, also a scope view and a freqview are IMHO needed.


On a meta level, IMHO it would be nice to have at least one other proposition. That would add the possibilty to choose between at least two options and then get at least one implemented. Any chance to get a second proposition? This should be possible I think; I mean that's seriously somehow strange that we only got one proposition so far. We may should set and distriubute a deadline... deadlines help almost always.

I hope that my comments make sense to you. They are again only based on my very subjective impressions (well, I guess GUI design is somehow a subjective business).

keep up the good work

cheers
Till


[1] http://en.wikipedia.org/wiki/Barber%27s_pole
[2] I did my own variation of Ben's proposition here: Loading Image...
Post by Scott Carver
There's nothing about pop-up menus in QT, at least, that necessitates them being the same width as the text+arrow component. But, design-wise, I'm not 100% sure what it would look like, so it would be good to mock it up first. I often use a super narrow pop-up menu (just the button) as a menu for doing actions (rather than selecting items from a list).
- Scott
Post by James Harkins
At Sun, 16 Jan 2011 22:34:01 +0000,
Post by thor
We now finally have a submitted design that is realistic and fit for
discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
It's pretty! I don't have specific criticisms.
It reminds me of one annoyance with SwingOSC, which I hope won't be replicated in supercute. IIRC in Cocoa, the menu in a pop-up menu can be wider than the pop-up menu view itself, if any of the strings in the menu is wide enough. In Swing, the menu is always the same width as the collapsed view. Sometimes you need to have a tiny box on the screen with longer strings inside. ("Well, why would you ever want to do that?" For instance, in MixerChannel, channel strips should not be too wide but the name of a target bus, listed in a pop-up menu, could easily be longer than the half a dozen characters that would fit inside the 50 pixels of the default definition.)
It just came to mind because the proposal page has a mockup of a pop-up menu where the view is wide but the strings are short. Just wondering what would happen if it's the other way around -- wishlist if nothing else.
w = Window("small menu", Rect(100, 100, 200, 120));
PopUpMenu(w, Rect(2, 2, 60, 20))
.items_(["Output bus 0", "Output bus 2", "Output bus 2"]);
w.front;
hjh
--
James Harkins /// dewdrop world
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
felix
2011-01-18 17:17:06 UTC
Permalink
(+) I think it is rather essential to be able to change the background to
a lighter/darker color, yet it should not destroy the overall look and feel.
since the edges are a hue-less shading effect, that just gets overlayed on
whatever color is used. so I think it should work fine.

the one limitation would be if your background was black, then the shading
would not be visible.
I'd love to see this sort of mockup. IMHO, there should also be a
recognizable difference between a view's background color (especially in the
textview) and the window's background color.
I think he chose nice shades, nicer then the current SC defaults. but in any
case all backgrounds and colors are customizable when you use the views.

nothing is changing compared to current guis : of course you can set the
colors.

IMO the default shades that he chose aren't worth much debate since they are
customizable anyway. they look great and he chose them because his designer
eye liked it, so we should leave it that way.

change it in your own code to anything you like.
(+) Are these GUI objects scaleable?
nothing is changing compared to the current gui system. it is the same
Button and same args. the same SC code would work.

this is just a design for how the edges, handles and shapes look.
there will be new views in the future and we would hope to implement them
using the same style.
I.e. is there also a big Knob?
if you make it big it will be big.
(+) I'd like to see log-grids accompanying the wonderful idea of a linear grid as proposed.
right, I also posted saying that various grids can be done. perhaps the
background would always be clear. then a slider/env/range etc. can be
created along with a container view behind it and any then the background
view can be anything you want.
LogGridBackground, GridBackground, PianoKeysBackground, LOLCatsBackground
etc
put a sample view behind it so that you scale your envelope directly over
the sample.
sound file view so you scale your automation envelopes over the track.
(+) Adding the possibility to show values (i.e. numbers) on
sliders/2dsliders/knobs, etc would be great. This would need some space for
the values, though.
or you could put the scaling on a background and make the slider slightly
transparent (with harder edges) and you can see the numbers through the
"glass"

you can also create a view that shows numbered ticks and place it directly
beside the slider.

all of this is usage and does not and should not IMO be put into the
slider/knob itself. its the same as putting a label on a fader. the fader
doesn't implement the label, its just paired with it in a composite view.

keep objects separate, reusable, combinable, throw-away-able, replaceable.
(+) Optinal axis description (i.e. numbers) around 2D-sliders,
multisliderviews and envelopeviews would be great to have.
of course you could do all of this today, right now


(+) The levelmeter IMHO should have the possibility to indicate clipping
place a single LED above the fader.
maybe you want a text up there to show how much it clicked by.
maybe click on it to reset it.

this is all usage, not part of the basic gui style design.
(+) I'd like to see an actual ContainerView implemented that can have a
colored outline (and optionally also a descriptive text) [2]
yes, that would be a useful general element !
(+) Please, some Radiobuttons.
true, more specifically a single round button in order to build radio
buttons.
(+) A native plot window a la plot2 would be neat, also a scope view and a
freqview are IMHO needed.
those already exist. all current sc views exist.
the current design is just a rectangle with no edge styling.

as I said in another mail: maybe a raised item to contrast the sunken item.
raised has the drop shadow outside (this means scaling the rectangle down by
the size of the shadow). same light source and angle as the sunken.

(btw. we should ask him what the angle is so we can recreate it for any
future views)

with sunken and raised edge designs then many variations can be made.

a scope could appear raised, or it could be a light background color and
sunken.

this would be a useful option for all/many widgets: no border / simple
curved edge / sunken / raised

a static text label could be raised giving a nice focus for that element.

a slider could use simple-curved edge, and next to it one using sunken.
cheers
Till
=felix
LFSaw
2011-01-18 19:20:39 UTC
Permalink
Hello,

(I allowed myself to re-add all points I made in my previous posting that felix ommited in his reply)

Just before the comments on the comments, I'd like to clarify my intends here. I understand the main objection felix made to my comments being that I mix up graphcal element design with interaction design elements. Anyhow, I have two points to make here. One is that some of the elements felix regards as being part of the interaction design process (e.g. plots, scopes and small/big knobs) should IMHO also be considered in the graphical part of the design process since their visual appearance should IMHO match to the ones of the other GUI elements. The other poitn is that Felix tries to convince me that basically everything I propose can already be made now, and that after the switch to the new GUI system it would just look different. IMHO, though, we should also talk about useful addons to
the semantics of GUI elements, which then includes e.g. LEDs in (a variation, or compund object) for e.g. levelmeters.
Post by Sc iss
Post by LFSaw
On a meta level, IMHO it would be nice to have at least one other proposition. That would add the possibilty to choose between at least two options and then get at least one implemented. Any chance to get a second proposition? This should be possible I think; I mean that's seriously somehow strange that we only got one proposition so far. We may should set and distriubute a deadline... deadlines help almost always.
(+) I like the idea to have the ability to color-code every gui element; that might help to visually connect elements that have something in common (i.e. they are, e.g. all controllers for the same synth). I understand that this has somehow also be represented in the round knob, however, IMHO its actual design in bens proposition looks a bit out of context to the other elements. Honestly, it reminds me of a certain circus emblem, or a barber's pole [1]. This is not a problem at all, however, I think that at least in a long-term usage, this would start to annoy me a bit. But that's just my impression.
since the edges are a hue-less shading effect, that just gets overlayed on whatever color is used. so I think it should work fine.
the one limitation would be if your background was black, then the shading would not be visible.
I am actually not talking about the shading (I'm not a big fan of shading effects btw.), but more about the knob designs (as others over in the sc-users thread already did)
Post by Sc iss
Post by LFSaw
(+) I'd like to support the points concerning the background colors of both views and background, made by other commenters in this thread. I think it is rather essential to be able to change the background to a lighter/darker color, yet it should not destroy the overall look and feel. I'd love to see this sort of mockup. IMHO, there should also be a recognizable difference between a view's background color (especially in the textview) and the window's background color.
I think he chose nice shades, nicer then the current SC defaults. but in any case all backgrounds and colors are customizable when you use the views.
which is to be debated upon.
Post by Sc iss
of course you can set the colors.
I assumed that. I wanted to say: we should decide on a nice default, since I (and I assume also many others) often just use the default. If you have to chasnge default everytime you want to use say a slider, then that default is not of great use.
Post by Sc iss
IMO the default shades that he chose aren't worth much debate since they are customizable anyway. they look great and he chose them because his designer eye liked it, so we should leave it that way.
IMHO this is the wron way if doing; I just suggested that it might be good to have another go on these shades, since I think that the currently used ones may not be optimal. That is something which I think should be considered already in the mockup. Again, I know that I can do basically everything by myself. I can of course also just code sliders by myself but IMHO that's not the point.
Post by Sc iss
change it in your own code to anything you like.
thanx :-)
Post by Sc iss
Post by LFSaw
(+) Are these GUI objects scaleable?
nothing is changing compared to the current gui system. it is the same Button and same args. the same SC code would work.
this is just a design for how the edges, handles and shapes look.
there will be new views in the future and we would hope to implement them using the same style.
Post by LFSaw
I.e. is there also a big Knob?
if you make it big it will be big.
by scaleable I meant, does the design scales in visual terms, i.e. maybe it would be good to have different designs for big knobs and small knobs because it might increases usability to differentiate between two cases (huuuge and smaaall).
Post by Sc iss
Post by LFSaw
(+) I'd like to see log-grids accompanying the wonderful idea of a linear grid as proposed.
right, I also posted saying that various grids can be done. perhaps the background would always be clear. then a slider/env/range etc. can be created along with a container view behind it and any then the background view can be anything you want.
LogGridBackground, GridBackground, PianoKeysBackground, LOLCatsBackground etc
put a sample view behind it so that you scale your envelope directly over the sample.
sound file view so you scale your automation envelopes over the track.
it happens that I stumbled across the posts over at sc-users only after I wrote this post. So yes, that's fine then.
Post by Sc iss
Post by LFSaw
(+) Adding the possibility to show values (i.e. numbers) on sliders/2dsliders/knobs, etc would be great. This would need some space for the values, though.
or you could put the scaling on a background and make the slider slightly transparent (with harder edges) and you can see the numbers through the "glass"
you can also create a view that shows numbered ticks and place it directly beside the slider.
all of this is usage and does not and should not IMO be put into the slider/knob itself. its the same as putting a label on a fader. the fader doesn't implement the label, its just paired with it in a composite view.
keep objects separate, reusable, combinable, throw-away-able, replaceable.
Post by LFSaw
(+) Optinal axis description (i.e. numbers) around 2D-sliders, multisliderviews and envelopeviews would be great to have.
of course you could do all of this today, right now
Post by LFSaw
(+) The levelmeter IMHO should have the possibility to indicate clipping
place a single LED above the fader.
maybe you want a text up there to show how much it clicked by.
maybe click on it to reset it.
then we need an LED-like object.
Post by Sc iss
this is all usage, not part of the basic gui style design.
Post by LFSaw
(+) I'd like to see an actual ContainerView implemented that can have a colored outline (and optionally also a descriptive text) [2]
yes, that would be a useful general element !
Post by LFSaw
(+) Please, some Radiobuttons.
true, more specifically a single round button in order to build radio buttons.
graphics-wise that is true, though, on an implementational level, I'd appreciate to have an (SC)RadioButton class, too.
Post by Sc iss
Post by LFSaw
(+) A native plot window a la plot2 would be neat, also a scope view and a freqview are IMHO needed.
those already exist. all current sc views exist.
the current design is just a rectangle with no edge styling.
I know. But as a post over at sc-users also pointed out, some of us think that also these items might have to match the style of the other GUI elements, so IMHO this is also part of the graphics that has to be designed.
Post by Sc iss
as I said in another mail: maybe a raised item to contrast the sunken item.
raised has the drop shadow outside (this means scaling the rectangle down by the size of the shadow). same light source and angle as the sunken.
(btw. we should ask him what the angle is so we can recreate it for any future views)
with sunken and raised edge designs then many variations can be made.
a scope could appear raised, or it could be a light background color and sunken.
this would be a useful option for all/many widgets: no border / simple curved edge / sunken / raised
a static text label could be raised giving a nice focus for that element.
a slider could use simple-curved edge, and next to it one using sunken.
that sounds reasonable.
Post by Sc iss
Post by LFSaw
cheers
Till
=felix
till

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
felix
2011-01-18 20:43:46 UTC
Permalink
Post by LFSaw
(I allowed myself to re-add all points I made in my previous posting that
felix ommited in his reply)
I only reply to things I had comments, solutions or implementation ideas
for.


The other poitn is that Felix tries to convince me that basically everything
Post by LFSaw
I propose can already be made now,
you read that incorrectly.

you had some points/questions/issues so I had some thoughts about how they
could be implemented. and then it occurred to me that those same solutions
would also work right now. and so I typed it happily into the email.

I was unconcerned about trying to convince you of anything.

but now I will try :

there is a certain debate (which is perhaps premature as nobody has got down
to looking at the particular Qt implementation) about which things should be
coded in C++ into EACH AND EVERY SLIDER and which things would be more
better as Slider + Background as composite SC objects (in the same vein as
NumberEditor and EZSlider).

the modularity and combinations could happen at the C++ or the SC level.

my strong impression is that the SC level is more flexible. especially if
you want to draw to the background. or animate it. etc. come up with a
better one, throw it out.

the win to doing it all in C++ is minimal. actually I can't think of any
win.

cons:

more memory, more arguments, more code, easier to break and harder to
re-implement on another graphics system. incompatible options with any of
the other GUI systems, incompatible with native components.



and that after the switch to the new GUI system it would just look
Post by LFSaw
different. IMHO, though, we should also talk about useful addons to the
semantics of GUI elements, which then includes e.g. LEDs in (a variation, or
compund object) for e.g. levelmeters.
well, sounds like the wrong direction of conversation to me. we can't even
agree on a background color, now you want to do design by committee for a
slider (for example) that will have backgrounds (perhaps behind, perhaps
beside), with wide flexibility of fonts, colors, grids, tick marks, a
numerical notation system that will support any idea that might occur in the
future ? settings and options enough to please everybody forever ?

the solution of setting the back to be transparent and then laying the grid
under is a good one I think. it opens up many possibilities for interesting
usage.
Post by LFSaw
Post by LFSaw
On a meta level, IMHO it would be nice to have at least one other
proposition. That would add the possibilty to choose between at least two
options and then get at least one implemented. Any chance to get a second
proposition?
Nobody else has submitted anything else.

then we need an LED-like object.
you know I've often had to use a static text view as a square. I then color
it or make it change colors. but these days you can use a user view and
just set the color. sadly though you cannot drag a text view.

if you want it to look really LED like then you could use an image, with two
photographs.

I did that server display actually with the LED style look. but I think
somebody changed it.

as a rule: SC users like to make their own things. they like their own look.
that's why they use such a weird thing as SC.


-felix
LFSaw
2011-01-18 21:32:48 UTC
Permalink
Hello,
Post by felix
Post by LFSaw
(I allowed myself to re-add all points I made in my previous posting that
felix ommited in his reply)
I only reply to things I had comments, solutions or implementation ideas
for.
Fair enough. I just wanted these things not to be lost.
Post by felix
Post by LFSaw
The other poitn is that Felix tries to convince me that basically everything
I propose can already be made now,
you read that incorrectly.
you had some points/questions/issues so I had some thoughts about how they
could be implemented. and then it occurred to me that those same solutions
would also work right now. and so I typed it happily into the email.
I was unconcerned about trying to convince you of anything.
So lets keep on being happy :-)
Post by felix
there is a certain debate (which is perhaps premature as nobody has got down
to looking at the particular Qt implementation) about which things should be
coded in C++ into EACH AND EVERY SLIDER and which things would be more
better as Slider + Background as composite SC objects (in the same vein as
NumberEditor and EZSlider).
the modularity and combinations could happen at the C++ or the SC level.
my strong impression is that the SC level is more flexible. especially if
you want to draw to the background. or animate it. etc. come up with a
better one, throw it out.
the win to doing it all in C++ is minimal. actually I can't think of any
win.
more memory, more arguments, more code, easier to break and harder to
re-implement on another graphics system. incompatible options with any of
the other GUI systems, incompatible with native components.
This is also my opinion. I completely agree with you.
Post by felix
Post by LFSaw
and that after the switch to the new GUI system it would just look
different. IMHO, though, we should also talk about useful addons to the
semantics of GUI elements, which then includes e.g. LEDs in (a variation, or
compund object) for e.g. levelmeters.
well, sounds like the wrong direction of conversation to me. we can't even
agree on a background color, now you want to do design by committee for a
slider (for example) that will have backgrounds (perhaps behind, perhaps
beside), with wide flexibility of fonts, colors, grids, tick marks, a
numerical notation system that will support any idea that might occur in the
future ? settings and options enough to please everybody forever ?
no. thats not my intention. moreover, my intention is to open a discussion about what might be reasonable interface compounds (definitely on an sc level) that then can be used thoroughly and consistently. Of course it is possible to flick everything together and use e.g. a view as a minimal element to get a colored object, however there IMHO should be a certain semantic behind the used GUI elements which somehow reflect its intended usage. IMHO a view is semantically not an object that one normally think of as a color indicator. Also, I think it would be a good opportunity to also actually *style* something like an LED.

So the proposal for needed base-material for a GUI theme would then include:

It would be nice to additionally have a design for
(1) Radio Buttons
(2) LED-like objects
(3) Colorable Framings for GUI compounds
(4) a "big knob" [1]


[1] I added knobs of several sizes to the screenshot: Loading Image... . This changed my opinion about that knob and I now think that it would actually be good to have a design of the knob that fits better for bigger knobs. Maybe we could handle this by keeping the width of the colored ring and the inner color circle's radius always the same, regardless of the knob's size... dunno.
Post by felix
the solution of setting the back to be transparent and then laying the grid
under is a good one I think. it opens up many possibilities for interesting
usage.
True. As long as this works for getting an exact grid representation that is scaleable and where I dont have to draw a pic everytine I need a different scaling, I'm fine with that. Only thing I'd suggest is that we should have compund objects (written in SC) that can be used to "just get that grid-version of that 2d slider".

Like:

2DGridSlider(parent, Rect(...)).

or

2DSlider(parent, Rect(...)).style(\grif).spec(aSpec) // grid determines wheter it is a log-grid or a linear grid based on Spec info.

No need to implement that into an actual 2dslider on qt layer.
Post by felix
Post by LFSaw
Post by LFSaw
On a meta level, IMHO it would be nice to have at least one other
proposition. That would add the possibilty to choose between at least two
options and then get at least one implemented. Any chance to get a second
proposition?
Nobody else has submitted anything else.
Post by LFSaw
then we need an LED-like object.
you know I've often had to use a static text view as a square. I then color
it or make it change colors. but these days you can use a user view and
just set the color. sadly though you cannot drag a text view.
if you want it to look really LED like then you could use an image, with two
photographs.
this actually is like programming your own custom gui object. I thought this is the purpose of this call, though: to have predefined looks for all standard GUI objects, like e.g. an LED object (if needed, incorporating a dropshadow).
Post by felix
I did that server display actually with the LED style look. but I think
somebody changed it.
as a rule: SC users like to make their own things. they like their own look.
that's why they use such a weird thing as SC.
Taking this to the extremes, this might also implie that we don't need that GUI thing at all, everyone can (and will) just use custom UserViews.
Post by felix
-felix
weird till :-)

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
felix
2011-01-18 22:31:38 UTC
Permalink
Post by LFSaw
my intention is to open a discussion about what might be reasonable
interface compounds (definitely on an sc level) that then can be used
thoroughly and consistently.
splendid.

and actually this discussion has worked quite well to imagine how we can use
these in combinatory and configurable ways. breaking it with our minds so
to speak.

Also, I think it would be a good opportunity to also actually *style*
Post by LFSaw
something like an LED.
well I guess musicians and LEDs *are* fond of one another.

can we get VU needles ballistics ?
Post by LFSaw
It would be nice to additionally have a design for
(1) Radio Buttons
(2) LED-like objects
(3) Colorable Framings for GUI compounds
(4) a "big knob" [1]
(5) Amorphous blob
(6) Complete set of emoticons (US/EU/JP)
(7) Epilepsy inducing background texture
(8) Pow/Shazam/Biff/Bam effects for enhanced user feedback
(9) Thought bubbles

actually Help bubbles are useful

waveshape / mapping function editing
Post by LFSaw
http://dl.dropbox.com/u/4046192/2011-SCGUI-Bens-proposition-variation.png. This changed my opinion about that knob and I now think that it would
actually be good to have a design of the knob that fits better for bigger
knobs. Maybe we could handle this by keeping the width of the colored ring
and the inner color circle's radius always the same, regardless of the
knob's size... dunno.
sounds reasonable.

simplest knob, IMO should be just like a current knob.
then a subclass that adds this range ring
and another one that has two range rings, especially good for mapping
external controllers (as Logic and Live do in their display)


how about:

2DSlider(parent,rect)
.background_( GridLines(spec) )

background would be aware of the bounds and can easily draw appropriate
lines

in the same way that background can be a Gradient or Color currently

currently SC requires the view to know about different expected types.
it would be simpler to just pass it a view.

color.asView would return a user view set to that color
gradient might return a view that can redraw the gradient correctly when
resized
LFSaw
2011-01-19 06:57:15 UTC
Permalink
Post by felix
Post by LFSaw
It would be nice to additionally have a design for
(1) Radio Buttons
(2) LED-like objects
(3) Colorable Framings for GUI compounds
(4) a "big knob" [1]
(5) Amorphous blob
(6) Complete set of emoticons (US/EU/JP)
(7) Epilepsy inducing background texture
(8) Pow/Shazam/Biff/Bam effects for enhanced user feedback
(9) Thought bubbles
this is ridiculous, or at least not really helpful.
I tried to make constructive input; this is clearly not.

thanx
Till

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Stefan Nussbaumer
2011-01-19 21:55:26 UTC
Permalink
Post by felix
actually Help bubbles are useful
too busy to chime in here but i kinda like that idea ... let's see.

stefan

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
felix
2011-01-19 22:57:41 UTC
Permalink
Live has a nice design pattern for help text: the help text is in a separate
pane and shows whenever you mouse over anything. much nicer then bubbles
IMO. you can close the pane if you don't need it.

http://soundcloud.com/crucialfelix
http://crucial-systems.com/timeblind
http://github.com/crucialfelix
Post by felix
actually Help bubbles are useful
too busy to chime in here but i kinda like that idea ... let's see.
stefan
_______________________________________________
sc-dev mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
ronald kuivila
2011-01-20 07:29:41 UTC
Permalink
Hi all,

Felix's comment about factoring between primitives (i.e. c++ code) and
the interpreter is really important.
Building integration features that move something from "possible" to
"convenient" in the interpreter (i.e, tick marks,
backgrounds, etc) is a wind. There is a larger programmer/debugger
base to maintain it and smoke out bugs.

RJK
Post by LFSaw
(I allowed myself to re-add all points I made in my previous posting
that felix ommited in his reply)
I only reply to things I had comments, solutions or implementation
ideas for.
The other poitn is that Felix tries to convince me that basically
everything I propose can already be made now,
you read that incorrectly.
you had some points/questions/issues so I had some thoughts about
how they could be implemented. and then it occurred to me that those
same solutions would also work right now. and so I typed it happily
into the email.
I was unconcerned about trying to convince you of anything.
there is a certain debate (which is perhaps premature as nobody has
got down to looking at the particular Qt implementation) about which
things should be coded in C++ into EACH AND EVERY SLIDER and which
things would be more better as Slider + Background as composite SC
objects (in the same vein as NumberEditor and EZSlider).
the modularity and combinations could happen at the C++ or the SC level.
my strong impression is that the SC level is more flexible.
especially if you want to draw to the background. or animate it.
etc. come up with a better one, throw it out.
the win to doing it all in C++ is minimal. actually I can't think
of any win.
more memory, more arguments, more code, easier to break and harder
to re-implement on another graphics system. incompatible options
with any of the other GUI systems, incompatible with native
components.
and that after the switch to the new GUI system it would just look
different. IMHO, though, we should also talk about useful addons to
the semantics of GUI elements, which then includes e.g. LEDs in (a
variation, or compund object) for e.g. levelmeters.
well, sounds like the wrong direction of conversation to me. we
can't even agree on a background color, now you want to do design by
committee for a slider (for example) that will have backgrounds
(perhaps behind, perhaps beside), with wide flexibility of fonts,
colors, grids, tick marks, a numerical notation system that will
support any idea that might occur in the future ? settings and
options enough to please everybody forever ?
the solution of setting the back to be transparent and then laying
the grid under is a good one I think. it opens up many
possibilities for interesting usage.
Post by LFSaw
On a meta level, IMHO it would be nice to have at least one other
proposition. That would add the possibilty to choose between at
least two options and then get at least one implemented. Any chance
to get a second proposition?
Nobody else has submitted anything else.
then we need an LED-like object.
you know I've often had to use a static text view as a square. I
then color it or make it change colors. but these days you can use
a user view and just set the color. sadly though you cannot drag a
text view.
if you want it to look really LED like then you could use an image,
with two photographs.
I did that server display actually with the LED style look. but I
think somebody changed it.
as a rule: SC users like to make their own things. they like their
own look. that's why they use such a weird thing as SC.
-felix
Lucas Samaruga
2011-01-18 18:42:38 UTC
Permalink
Post by LFSaw
knob, however, IMHO its actual design in bens proposition looks a bit out
of context to the other elements. Honestly, it reminds me of a certain
circus emblem, or a barber's pole [1].
[1] http://en.wikipedia.org/wiki/Barber%27s_pole
Nope, your are really wrong, it looks like this

Loading Image...

<http://www.vectorizados.com/muestras/tiro-al-blanco-2.jpg>:-)
sorry, sorry.
Scott Carver
2011-01-18 19:53:35 UTC
Permalink
The group boxes in this mockup are very slick - I like.

- Scott
Post by LFSaw
[1] http://en.wikipedia.org/wiki/Barber%27s_pole
[2] I did my own variation of Ben's proposition here: http://dl.getdropbox.com/u/4046192/2011-SCGUI-Bens-proposition-variation.png
Scott Carver
2011-01-17 19:03:08 UTC
Permalink
Thor -

Any way you could post a png version of the mockup screenshot on the wiki?
Trying to take a closer look but the jpg is a bit artifact-y.

Thanks,
Scott Carver
Post by thor
Hello colliders
As many are aware of, SuperCollider is now being implemented in a new GUI framework called Qt ( http://qt.nokia.com/ ). There was a thread on the look of that GUI : http://www.listarc.bham.ac.uk/lists/sc-dev/msg19324.html and we subsequently set up a dedicated project for this on the Wiki page here: http://supercollider.sourceforge.net/wiki/index.php/GUI_Design_project
We now finally have a submitted design that is realistic and fit for discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
The design of these GUI elements will be implemented in Qt and therefore giving SC a unique look that is still minimal and neutral. The question of native versus SC style look is something we might want to discuss. Also it would be good if people would submit their wish list for new widgets (or new features to existing widgets) to be implemented.
Note that this is a sketch that will be further refined when written in Qt and one that is put forth for the sake of discussion, not as the final design.
So opinions, suggestions, wish list items, etc. welcome. Also, if someone has alternative designs or wants to have a go at refining this current design, please go ahead.
thor
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Sc iss
2011-01-18 17:39:28 UTC
Permalink
sorry to disagree once more with you, felix. but the mere solution of saying well you can create a log background and place it under the view, you can create a ticks view and place it next to the slider, and an led-like button and place it above the level meter, will recreate exactly the mess that the current GUI is suffering from : everyone is doing this themselves by hand, counting pixels, and so forth. and then, one day, when a slider as pixel or or less on any side, the pretty layout is gone. or change a font size, and then redo all the work.

separation of objects, yes, but we need semantic grouping of objects. and getting rid of pixel bounds (at least make them optional). why not add a tick decorator to the slider, a grid decorator to area filling objects, and so on. the layout algorithm will take care that they get properly aligned, but you will still be able to exchange the decorators.

one thing they did right in java's swing, although a little bit late in the history, is baseline alignments, as an example. you have a layout and you tell it two components match in their baselines. doesn't matter where exactly vertically a text appears in a button, the layout takes care that the button text and a neighbouring label's text look fine together.

nothing against DIY gui fabrication and manual pixel tuning, but i think a little bit more autonomous decisions from the GUI systems don't do any harm.

best, -sciss-




----- original message --------

Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: felix


On Tue, Jan 18, 2011 at 5:10 PM, LFSaw <lfsaw-mvlOuy+***@public.gmane.org> wrote:
(+) I think it is rather essential to be able to change the background to a lighter/darker color, yet it should not destroy the overall look and feel.
since the edges are a hue-less shading effect, that just gets overlayed on whatever color is used. so I think it should work fine.
the one limitation would be if your background was black, then the shading would not be visible.
I'd love to see this sort of mockup. IMHO, there should also be a recognizable difference between a view's background color (especially in the textview) and the window's background color.

I think he chose nice shades, nicer then the current SC defaults. but in any case all backgrounds and colors are customizable when you use the views.
nothing is changing compared to current guis : of course you can set the colors.
IMO the default shades that he chose aren't worth much debate since they are customizable anyway. they look great and he chose them because his designer eye liked it, so we should leave it that way.
change it in your own code to anything you like.

(+) Are these GUI objects scaleable?
nothing is changing compared to the current gui system. it is the same Button and same args. the same SC code would work.
this is just a design for how the edges, handles and shapes look.there will be new views in the future and we would hope to implement them using the same style.
I.e. is there also a big Knob?

if you make it big it will be big.

(+) I'd like to see log-grids accompanying the wonderful idea of a linear grid as proposed.

right, I also posted saying that various grids can be done. perhaps the background would always be clear. then a slider/env/range etc. can be created along with a container view behind it and any then the background view can be anything you want.LogGridBackground, GridBackground, PianoKeysBackground, LOLCatsBackground etcput a sample view behind it so that you scale your envelope directly over the sample.sound file view so you scale your automation envelopes over the track.
(+) Adding the possibility to show values (i.e. numbers) on sliders/2dsliders/knobs, etc would be great. This would need some space for the values, though.

or you could put the scaling on a background and make the slider slightly transparent (with harder edges) and you can see the numbers through the "glass"
you can also create a view that shows numbered ticks and place it directly beside the slider.
all of this is usage and does not and should not IMO be put into the slider/knob itself. its the same as putting a label on a fader. the fader doesn't implement the label, its just paired with it in a composite view.
keep objects separate, reusable, combinable, throw-away-able, replaceable.

(+) Optinal axis description (i.e. numbers) around 2D-sliders, multisliderviews and envelopeviews would be great to have.

of course you could do all of this today, right now

(+) The levelmeter IMHO should have the possibility to indicate clipping

place a single LED above the fader.maybe you want a text up there to show how much it clicked by.maybe click on it to reset it.
this is all usage, not part of the basic gui style design.


(+) I'd like to see an actual ContainerView implemented that can have a colored outline (and optionally also a descriptive text) [2]

yes, that would be a useful general element ! (+) Please, some Radiobuttons.

true, more specifically a single round button in order to build radio buttons.
(+) A native plot window a la plot2 would be neat, also a scope view and a freqview are IMHO needed.

those already exist. all current sc views exist.the current design is just a rectangle with no edge styling.
as I said in another mail: maybe a raised item to contrast the sunken item.raised has the drop shadow outside (this means scaling the rectangle down by the size of the shadow). same light source and angle as the sunken.
(btw. we should ask him what the angle is so we can recreate it for any future views)
with sunken and raised edge designs then many variations can be made.
a scope could appear raised, or it could be a light background color and sunken.
this would be a useful option for all/many widgets: no border / simple curved edge / sunken / raised
a static text label could be raised giving a nice focus for that element.
a slider could use simple-curved edge, and next to it one using sunken.



cheers
Till


=felix


--- original message end ----
Scott Carver
2011-01-18 19:53:33 UTC
Permalink
I'm in hearty agreement.

Though - if this is to be taken seriously, I don't think the idea of keeping around the current UI paradigms is an option. Fixing these issues, streamlining ui creation, making use of decorators (i.e. grids/rulers) and layout tools, is going to be best served by some rethinking of SC's UI patterns.

In talking about this, it would be beneficial to stick to specific use cases, too. For example - you need to create six sliders to control six parameters, based on six control busses. Each has an associated spec. Their layout, markings, color, and labeling needs to be clean, pretty, (nearly) automatic, and flexible such that they can be incorporated into other UI later. They need to be properly MVC - so if the values are changed from elsewhere, the sliders are updated. Despite the fact that this is maybe the #1 most common UI in SC, this is the SuperCollider hello world, I can't think of any way of building the above (even as an experienced user) without (a) a ton of code, (b) extensive consultation of docs, (c) reliance on much higher-level toolkits (Crucial/CTK/jit/etc) which bring with them their own extensive paradigms and specific uses.

I think it's worth taking cases like that - looking at both the UI and the code it takes to build that UI - and figuring out what will make it cleaner, easier, more flexible, and prettier on both sides. Sciss, Felix - if you wanted a slider with a particular range and log-scale tick marks, what should the code/ui look like? What components would be required?

Scott Carver
Post by Sc iss
sorry to disagree once more with you, felix. but the mere solution of saying well you can create a log background and place it under the view, you can create a ticks view and place it next to the slider, and an led-like button and place it above the level meter, will recreate exactly the mess that the current GUI is suffering from : everyone is doing this themselves by hand, counting pixels, and so forth. and then, one day, when a slider as pixel or or less on any side, the pretty layout is gone. or change a font size, and then redo all the work.
separation of objects, yes, but we need semantic grouping of objects. and getting rid of pixel bounds (at least make them optional). why not add a tick decorator to the slider, a grid decorator to area filling objects, and so on. the layout algorithm will take care that they get properly aligned, but you will still be able to exchange the decorators.
one thing they did right in java's swing, although a little bit late in the history, is baseline alignments, as an example. you have a layout and you tell it two components match in their baselines. doesn't matter where exactly vertically a text appears in a button, the layout takes care that the button text and a neighbouring label's text look fine together.
nothing against DIY gui fabrication and manual pixel tuning, but i think a little bit more autonomous decisions from the GUI systems don't do any harm.
best, -sciss-
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: felix
(+) I think it is rather essential to be able to change the background to a lighter/darker color, yet it should not destroy the overall look and feel.
since the edges are a hue-less shading effect, that just gets overlayed on whatever color is used. so I think it should work fine.
the one limitation would be if your background was black, then the shading would not be visible.
I'd love to see this sort of mockup. IMHO, there should also be a recognizable difference between a view's background color (especially in the textview) and the window's background color.
I think he chose nice shades, nicer then the current SC defaults. but in any case all backgrounds and colors are customizable when you use the views.
nothing is changing compared to current guis : of course you can set the colors.
IMO the default shades that he chose aren't worth much debate since they are customizable anyway. they look great and he chose them because his designer eye liked it, so we should leave it that way.
change it in your own code to anything you like.
(+) Are these GUI objects scaleable?
nothing is changing compared to the current gui system. it is the same Button and same args. the same SC code would work.
this is just a design for how the edges, handles and shapes look.there will be new views in the future and we would hope to implement them using the same style.
I.e. is there also a big Knob?
if you make it big it will be big.
(+) I'd like to see log-grids accompanying the wonderful idea of a linear grid as proposed.
right, I also posted saying that various grids can be done. perhaps the background would always be clear. then a slider/env/range etc. can be created along with a container view behind it and any then the background view can be anything you want.LogGridBackground, GridBackground, PianoKeysBackground, LOLCatsBackground etcput a sample view behind it so that you scale your envelope directly over the sample.sound file view so you scale your automation envelopes over the track.
(+) Adding the possibility to show values (i.e. numbers) on sliders/2dsliders/knobs, etc would be great. This would need some space for the values, though.
or you could put the scaling on a background and make the slider slightly transparent (with harder edges) and you can see the numbers through the "glass"
you can also create a view that shows numbered ticks and place it directly beside the slider.
all of this is usage and does not and should not IMO be put into the slider/knob itself. its the same as putting a label on a fader. the fader doesn't implement the label, its just paired with it in a composite view.
keep objects separate, reusable, combinable, throw-away-able, replaceable.
(+) Optinal axis description (i.e. numbers) around 2D-sliders, multisliderviews and envelopeviews would be great to have.
of course you could do all of this today, right now
(+) The levelmeter IMHO should have the possibility to indicate clipping
place a single LED above the fader.maybe you want a text up there to show how much it clicked by.maybe click on it to reset it.
this is all usage, not part of the basic gui style design.
(+) I'd like to see an actual ContainerView implemented that can have a colored outline (and optionally also a descriptive text) [2]
yes, that would be a useful general element ! (+) Please, some Radiobuttons.
true, more specifically a single round button in order to build radio buttons.
(+) A native plot window a la plot2 would be neat, also a scope view and a freqview are IMHO needed.
those already exist. all current sc views exist.the current design is just a rectangle with no edge styling.
as I said in another mail: maybe a raised item to contrast the sunken item.raised has the drop shadow outside (this means scaling the rectangle down by the size of the shadow). same light source and angle as the sunken.
(btw. we should ask him what the angle is so we can recreate it for any future views)
with sunken and raised edge designs then many variations can be made.
a scope could appear raised, or it could be a light background color and sunken.
this would be a useful option for all/many widgets: no border / simple curved edge / sunken / raised
a static text label could be raised giving a nice focus for that element.
a slider could use simple-curved edge, and next to it one using sunken.
cheers
Till
=felix
--- original message end ----
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Miguel Negrao
2011-01-19 14:01:29 UTC
Permalink
Post by Scott Carver
I'm in hearty agreement.
Though - if this is to be taken seriously, I don't think the idea of keeping around the current UI paradigms is an option. Fixing these issues, streamlining ui creation, making use of decorators (i.e. grids/rulers) and layout tools, is going to be best served by some rethinking of SC's UI patterns.
In talking about this, it would be beneficial to stick to specific use cases, too. For example - you need to create six sliders to control six parameters, based on six control busses. Each has an associated spec. Their layout, markings, color, and labeling needs to be clean, pretty, (nearly) automatic, and flexible such that they can be incorporated into other UI later. They need to be properly MVC - so if the values are changed from elsewhere, the sliders are updated. Despite the fact that this is maybe the #1 most common UI in SC, this is the SuperCollider hello world, I can't think of any way of building the above (even as an experienced user) without (a) a ton of code, (b) extensive consultation of docs, (c) reliance on much higher-level toolkits (Crucial/CTK/jit/etc) which bring with them their own extensive paradigms and specific uses.
I quite agree with this ! I think there should be standard way to do MVC, with a neat tutorial, that allows you to quickly make some guis.
Another thing which I thing is missing, connected with MVC, although all the ingredients are available, is a Document framework, so that you can bundle all the data from those MVC guis and save it to disk, and then do the reverse, load from disk and update the views. All of this could be made mostly automatic. Most people need to do this at some time of another, and there’s no really unified system to deal with this.
Me personally,I use the .changed notification system, together with building a document that gets the values from the all the models, and then I call .writeArchive on that. Would be nice thought to have even an xml file saver, where this Document could be some simple dictionary with multiple nested dictionaries of whatever configuration one wants. Something like:

(synths: [ (\freq, 400, \amp,0.5), (\freq, 200, \amp,0.1)], \bufferPaths: [ “path1”, “path2” ] )

So one would just specify the layout of this dictionary, and connect each field to the corresponding model, and everything else would work out of the box.

Would be nice to also get undo/redo for free, and preset management (which would just be a kind of version management of the document).
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
felix
2011-01-19 15:00:50 UTC
Permalink
On Wed, Jan 19, 2011 at 3:01 PM, Miguel Negrao <
Post by Scott Carver
They need to be properly MVC - so if the values are changed from
elsewhere, the sliders are updated. Despite the fact that this is maybe the
#1 most common UI in SC, this is the SuperCollider hello world, I can't
think of any way of building the above (even as an experienced user) without
(a) a ton of code, (b) extensive consultation of docs, (c) reliance on much
higher-level toolkits (Crucial/CTK/jit/etc) which bring with them their own
extensive paradigms and specific uses.
ObjectGui

this is not part of crucial anymore. there is very little paradigm and only
a few methods really. it is a straight MVC architecture.

.gui an object, it creates a gui of using the related guiClass

when model changes, gui is updated.
window closes, dependency is released.

that's it


it was recently cleaned up and simplified and the docs improved

feedback and criticism gratefully accepted

I could move even "writeName" out of the class so it looks even simpler and
try to encourage more people to use and write gui classes, but I get the
feeling that the community would then hop in and start adding tons of
features and bog the class down as happened to Document.
Scott Carver
2011-01-20 01:10:40 UTC
Permalink
Post by Miguel Negrao
Would be nice to also get undo/redo for free, and preset management (which would just be a kind of version management of the document).
To only address one tiny part of your post...
:)

Undo and redo "for free" is hard. Preset management, in SC, is also a bit hard because there are a million different ways you can have a values that affect synths, so there's no universal way to say "give me all the settings for my current state" (unlike Max, where you can just grab the output of all your UI nodes in the patch). I've built a few different solutions for "presets" and I've always found that, where I thought I was doing something very general or universal, I was actually building something very specific to the use-case at hand. SC is just too mutable, I think, to build a universal preset system that would work with every way of doing things. It could certainly be made easier, however...

And - if we want to fantasize about built-in undo/redo/presetting in SC, I would imagine it looking something like this:

bus = Bus.control(s,1);
busModel = bus.asModel;
busModel.spec = someSpec;

SCSlider(...).model_(busModel);
UndoManager.get(\thisProject).addModel( busModel )

busModel.value = 400; // triggers updates of slider and undo history item
UndoManger.get(\thisProject).undo(); // sets the model in question back to it's previous value, again triggering updates

Though maybe there are cleaner ways than this, who knows.

Scott
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
felix
2011-01-20 01:51:38 UTC
Permalink
good points scott. further to that:

Undo managers almost always work by pushing a function that would set the
state back to where it was and then after that setting the value.

currvarx = varx;
currvary = vary;
UndoManager.push( { varx = currvarx; vary = currvary;});

// ready to set new things
varx = newx;
vary = newy;


normal/complex situations require you to do more to reset the state, like
trigger updates/changed, reset play heads etc.

also, undo is never a part of the document, it is a part of the editing
application.



http://soundcloud.com/crucialfelix
http://crucial-systems.com/timeblind
http://github.com/crucialfelix
Post by Miguel Negrao
Post by Miguel Negrao
Would be nice to also get undo/redo for free, and preset management
(which would just be a kind of version management of the document).
To only address one tiny part of your post...
:)
Undo and redo "for free" is hard. Preset management, in SC, is also a bit
hard because there are a million different ways you can have a values that
affect synths, so there's no universal way to say "give me all the settings
for my current state" (unlike Max, where you can just grab the output of all
your UI nodes in the patch). I've built a few different solutions for
"presets" and I've always found that, where I thought I was doing something
very general or universal, I was actually building something very specific
to the use-case at hand. SC is just too mutable, I think, to build a
universal preset system that would work with every way of doing things. It
could certainly be made easier, however...
And - if we want to fantasize about built-in undo/redo/presetting in SC, I
bus = Bus.control(s,1);
busModel = bus.asModel;
busModel.spec = someSpec;
SCSlider(...).model_(busModel);
UndoManager.get(\thisProject).addModel( busModel )
busModel.value = 400; // triggers updates of slider and undo history item
UndoManger.get(\thisProject).undo(); // sets the model in question
back to it's previous value, again triggering updates
Though maybe there are cleaner ways than this, who knows.
Scott
_______________________________________________
sc-dev mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Miguel Negrao
2011-01-20 10:01:03 UTC
Permalink
Hi Felix,
Undo managers almost always work by pushing a function that would set the state back to where it was and then after that setting the value.
or you can use the brute force approach is to just save the whole state at every change, which makes the implementation a lot easier but uses more memory. I use this approach...
currvarx = varx;
currvary = vary;
UndoManager.push( { varx = currvarx; vary = currvary;});
// ready to set new things
varx = newx;
vary = newy;
normal/complex situations require you to do more to reset the state, like trigger updates/changed, reset play heads etc.
That’s why have mvc, if you need something to hapspen when varx is updated then you should register for notifications with a controller. Then you just do

varx.value_(newx).changed.
also, undo is never a part of the document, it is a part of the editing application.
that’s true.

best,
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
James Harkins
2011-01-20 02:04:07 UTC
Permalink
At Wed, 19 Jan 2011 17:10:40 -0800,
Post by Scott Carver
Preset management, in SC, is also a bit hard because there are a million different ways you can have a values that affect synths, so there's no universal way to say "give me all the settings for my current state" (unlike Max, where you can just grab the output of all your UI nodes in the patch). I've built a few different solutions for "presets" and I've always found that, where I thought I was doing something very general or universal, I was actually building something very specific to the use-case at hand.
Hm... maybe we need a separate thread for preset management issues.

Or maybe we don't -- Ron Kuivila's Preset is pretty damn brilliant. What would be involved in making it undoable and save-able?


Anyway, I use my GenericGlobalControl a lot for this sort of thing (though I haven't yet done much with saving/loading presets -- started on a framework but never finished).

- Integrates easily with Voicer global controls in my performance GUI (including MIDI mapping).

- MVC ready.

- Its value is available in a client side variable and server-side control bus. The value can be manipulated from both sides -- 'automate' makes a synth that writes to the control bus and 'watch' (optionally) makes the client-side value follow the control bus. Then, setting the value on the client side stops automation.

- Pattern integration: aGlobalControl.asStream --> Pfunc({ aGlobalControl.value }).asStream.

- Synth argument integration: Synth(\something, [ffreq: aGlobalControl]) automatically does 'asMap' on the control. (Similar for Instr/Patch, though the mechanism is slightly different.)

It doesn't handle array structures, though, but maybe that's just because I haven't written a GenericArrayControl yet :)

hjh


--
James Harkins /// dewdrop world
jamshark70-***@public.gmane.org
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Miguel Negrao
2011-01-20 10:12:28 UTC
Permalink
Post by James Harkins
At Wed, 19 Jan 2011 17:10:40 -0800,
Post by Scott Carver
Preset management, in SC, is also a bit hard because there are a million different ways you can have a values that affect synths, so there's no universal way to say "give me all the settings for my current state" (unlike Max, where you can just grab the output of all your UI nodes in the patch). I've built a few different solutions for "presets" and I've always found that, where I thought I was doing something very general or universal, I was actually building something very specific to the use-case at hand.
Hm... maybe we need a separate thread for preset management issues.
Or maybe we don't -- Ron Kuivila's Preset is pretty damn brilliant. What would be involved in making it undoable and save-able?
Where can I take a look at this class ? Can’t find it in the quarks...

thanks,
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
James Harkins
2011-01-20 12:14:34 UTC
Permalink
At Thu, 20 Jan 2011 11:12:28 +0100,
Where can I take a look at this class ? Can’t find it in the quarks...
Part of Conductor IIRC (or maybe I got the name wrong, quite possible).
hjh


--
James Harkins /// dewdrop world
jamshark70-***@public.gmane.org
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman

blog: http://www.dewdrop-world.net/words
audio clips: http://www.dewdrop-world.net/audio
more audio: http://soundcloud.com/dewdrop_world/tracks

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Miguel Negrao
2011-01-20 09:57:55 UTC
Permalink
Post by Scott Carver
Post by Miguel Negrao
Would be nice to also get undo/redo for free, and preset management (which would just be a kind of version management of the document).
To only address one tiny part of your post...
:)
Undo and redo "for free" is hard. Preset management, in SC, is also a bit hard because there are a million different ways you can have a values that affect synths, so there's no universal way to say "give me all the settings for my current state" (unlike Max, where you can just grab the output of all your UI nodes in the patch).
Yes that’s quite true. But if you use an MVC model, then when you load a configuration from file you put the values back in the models, and whoever needs those values, be it guis, synths, or whatever should be registered to get .changed notifications. That way, the data is completely abstracted from what it is controlling. This works quite well, I’ve been doing it in some of my projects.
Post by Scott Carver
I've built a few different solutions for "presets" and I've always found that, where I thought I was doing something very general or universal, I was actually building something very specific to the use-case at hand. SC is just too mutable, I think, to build a universal preset system that would work with every way of doing things. It could certainly be made easier, however...
Well, what you can do with Cocoa framework is also very broad and they do have a CoreData framework for document management... If you make the model general enough, it should cover at least a good percentage of normal usage cases.

best,
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
Julian Rohrhuber
2011-01-20 12:30:57 UTC
Permalink
Post by Scott Carver
Post by Miguel Negrao
Would be nice to also get undo/redo for free, and preset management (which would just be a kind of version management of the document).
To only address one tiny part of your post...
:)
Undo and redo "for free" is hard. Preset management, in SC, is also a bit hard because there are a million different ways you can have a values that affect synths, so there's no universal way to say "give me all the settings for my current state" (unlike Max, where you can just grab the output of all your UI nodes in the patch).
Yes that’s quite true. But if you use an MVC model, then when you load a configuration from file you put the values back in the models, and whoever needs those values, be it guis, synths, or whatever should be registered to get .changed notifications. That way, the data is completely abstracted from what it is controlling. This works quite well, I’ve been doing it in some of my projects.
Done properly, polling allows objects to be more completely uncoupled than with event-driven MVC, for at least two reasons:

* there is no need to implement an interface for it in the model: anything can be a model as is.
* the model doesn't need a set of all other objects interested in it, but those who are interested know what they need.
* timing needs not be controlled by the model: it is not presupposed that a certain change matters to a view, but the view looks it up

What paradigm is better depends on the case, so I don't believe there should be one pattern exclusively suggested in the system.
Also it is not certain that only data that is part of the interaction with a GUI is the one that is required for restoring an object's state.

I do think that a generalisation of updating (a dedicated object which supports different MVC paradigms) would be helpful also for separating what is essential about an object from its arbitrary and momentary state.




_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Miguel Negrao
2011-01-20 12:47:16 UTC
Permalink
Post by Julian Rohrhuber
Post by Miguel Negrao
Post by Scott Carver
Post by Miguel Negrao
Would be nice to also get undo/redo for free, and preset management (which would just be a kind of version management of the document).
To only address one tiny part of your post...
:)
Undo and redo "for free" is hard. Preset management, in SC, is also a bit hard because there are a million different ways you can have a values that affect synths, so there's no universal way to say "give me all the settings for my current state" (unlike Max, where you can just grab the output of all your UI nodes in the patch).
Yes that’s quite true. But if you use an MVC model, then when you load a configuration from file you put the values back in the models, and whoever needs those values, be it guis, synths, or whatever should be registered to get .changed notifications. That way, the data is completely abstracted from what it is controlling. This works quite well, I’ve been doing it in some of my projects.
* there is no need to implement an interface for it in the model: anything can be a model as is.
* the model doesn't need a set of all other objects interested in it, but those who are interested know what they need.
* timing needs not be controlled by the model: it is not presupposed that a certain change matters to a view, but the view looks it up
What paradigm is better depends on the case, so I don't believe there should be one pattern exclusively suggested in the system.
Also it is not certain that only data that is part of the interaction with a GUI is the one that is required for restoring an object's state.
I do think that a generalisation of updating (a dedicated object which supports different MVC paradigms) would be helpful also for separating what is essential about an object from its arbitrary and momentary state.
I don’t know if I understood correctly, but are you suggesting that a gui would be polling the value of a model every couple of miliseconds to see it changed ? That doesn’t sound very efficient or elegant, specially given how slow sclang is... But maybe I’m not understanding it correctly...

Actually I think in this area and many others the lack of a pattern explicitly suggested in the system leaves most users completely in the dark, without using any pattern at all, or using very bad ones. Then some of the advanced user have their own customs systems that almost only they use, and this contributes to the fragmentation of supercollider which I see in many areas (see for instance the midi controller discussion in another thread). Whatever is the best pattern, and that is up for discussion, I think it should be declared the official one, and used in every single help file, so that it’s very clear and simple to use for most users. Advanced users can always make their own systems.

best regards,
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
felix
2011-01-20 14:49:15 UTC
Permalink
and the other way is to use signals with NotificationCenter

I've gotten annoyed by using the dependency model all the time. its ok for
simple objects but you end up having to pass arguments to
changed('whatChanged') and then all the dependent objects choose whether
they are interested or not.

an object that represents an application has many signals to emit, it isn't
a single thing that changes. a lot of changed messages really aren't
anything to do with the model changing, its just using that system to send a
signal.

with NotificationCenter there is no coupling to the model, but of course if
the window closes and the gui ceases to exist then it needs to unregister
itself.

so with dependency system: the model might be kept in GC by an accidental
hanging link to a gui dependent (in practice not a problem if you use
ObjectGui or Updater)

with NotificationCenter: a gui might be kept in GC if it isn't released
correctly when closing.



On Thu, Jan 20, 2011 at 1:30 PM, Julian Rohrhuber
Post by Julian Rohrhuber
Done properly, polling allows objects to be more completely uncoupled than
* there is no need to implement an interface for it in the model: anything
can be a model as is.
? nothing needs to be implemented in the model for MVC. unless you mean
the dependency system, but that's in Object

* the model doesn't need a set of all other objects interested in it, but
Post by Julian Rohrhuber
those who are interested know what they need.
the model doesn't keep any such list.
the method to add a dependent is on Object,
but that's just the entry point to the dependency framework.
Object dependantsDictionary stores the links



http://soundcloud.com/crucialfelix
http://crucial-systems.com/timeblind
http://github.com/crucialfelix
ronald kuivila
2011-01-20 07:19:14 UTC
Permalink
Hi Scott,

I think the CV class from my Conductor Quark might of interest as a
design approach. The basic idea is to represent all control values
(which might be an array of values or a symbol as well as a single
Float) as objects of the same class. That class defines the widgetry
to link to everything else in the system (i.e., controls in synths
groups, patterns in the language, GUI's, etc). This makes it easier
for the user as one interface manages all forms of control and easier
for the programmer as everything passes through this one class of
objects.

While CV works with notifications, Alberto DeCampo's SkipJack uses
polling. This has real advantages as it allows the GUI
to ignore high speed changes that would otherwise bog down the
system. But it can also slow down the passage of external controls
to the server. So a hybrid approach might be best.


RJK
Post by Scott Carver
I'm in hearty agreement.
Though - if this is to be taken seriously, I don't think the idea of
keeping around the current UI paradigms is an option. Fixing these
issues, streamlining ui creation, making use of decorators (i.e.
grids/rulers) and layout tools, is going to be best served by some
rethinking of SC's UI patterns.
In talking about this, it would be beneficial to stick to specific
use cases, too. For example - you need to create six sliders to
control six parameters, based on six control busses. Each has an
associated spec. Their layout, markings, color, and labeling needs
to be clean, pretty, (nearly) automatic, and flexible such that they
can be incorporated into other UI later. They need to be properly
MVC - so if the values are changed from elsewhere, the sliders are
updated. Despite the fact that this is maybe the #1 most common UI
in SC, this is the SuperCollider hello world, I can't think of any
way of building the above (even as an experienced user) without (a)
a ton of code, (b) extensive consultation of docs, (c) reliance on
much higher-level toolkits (Crucial/CTK/jit/etc) which bring with
them their own extensive paradigms and specific uses.
I think it's worth taking cases like that - looking at both the UI
and the code it takes to build that UI - and figuring out what will
make it cleaner, easier, more flexible, and prettier on both sides.
Sciss, Felix - if you wanted a slider with a particular range and
log-scale tick marks, what should the code/ui look like? What
components would be required?
Scott Carver
Post by Sc iss
sorry to disagree once more with you, felix. but the mere solution
of saying well you can create a log background and place it under
the view, you can create a ticks view and place it next to the
slider, and an led-like button and place it above the level meter,
will recreate exactly the mess that the current GUI is suffering
from : everyone is doing this themselves by hand, counting pixels,
and so forth. and then, one day, when a slider as pixel or or less
on any side, the pretty layout is gone. or change a font size, and
then redo all the work.
separation of objects, yes, but we need semantic grouping of
objects. and getting rid of pixel bounds (at least make them
optional). why not add a tick decorator to the slider, a grid
decorator to area filling objects, and so on. the layout algorithm
will take care that they get properly aligned, but you will still
be able to exchange the decorators.
one thing they did right in java's swing, although a little bit
late in the history, is baseline alignments, as an example. you
have a layout and you tell it two components match in their
baselines. doesn't matter where exactly vertically a text appears
in a button, the layout takes care that the button text and a
neighbouring label's text look fine together.
nothing against DIY gui fabrication and manual pixel tuning, but i
think a little bit more autonomous decisions from the GUI systems
don't do any harm.
best, -sciss-
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: felix
(+) I think it is rather essential to be able to change the
background to a lighter/darker color, yet it should not destroy the
overall look and feel.
since the edges are a hue-less shading effect, that just gets
overlayed on whatever color is used. so I think it should work fine.
the one limitation would be if your background was black, then the
shading would not be visible.
I'd love to see this sort of mockup. IMHO, there should also be a
recognizable difference between a view's background color
(especially in the textview) and the window's background color.
I think he chose nice shades, nicer then the current SC defaults.
but in any case all backgrounds and colors are customizable when
you use the views.
nothing is changing compared to current guis : of course you can set the colors.
IMO the default shades that he chose aren't worth much debate since
they are customizable anyway. they look great and he chose them
because his designer eye liked it, so we should leave it that way.
change it in your own code to anything you like.
(+) Are these GUI objects scaleable?
nothing is changing compared to the current gui system. it is the
same Button and same args. the same SC code would work.
this is just a design for how the edges, handles and shapes
look.there will be new views in the future and we would hope to
implement them using the same style.
I.e. is there also a big Knob?
if you make it big it will be big.
(+) I'd like to see log-grids accompanying the wonderful idea of a
linear grid as proposed.
right, I also posted saying that various grids can be done.
perhaps the background would always be clear. then a slider/env/
range etc. can be created along with a container view behind it and
any then the background view can be anything you
want.LogGridBackground, GridBackground, PianoKeysBackground,
LOLCatsBackground etcput a sample view behind it so that you scale
your envelope directly over the sample.sound file view so you scale
your automation envelopes over the track.
(+) Adding the possibility to show values (i.e. numbers) on sliders/
2dsliders/knobs, etc would be great. This would need some space for
the values, though.
or you could put the scaling on a background and make the slider
slightly transparent (with harder edges) and you can see the
numbers through the "glass"
you can also create a view that shows numbered ticks and place it
directly beside the slider.
all of this is usage and does not and should not IMO be put into
the slider/knob itself. its the same as putting a label on a
fader. the fader doesn't implement the label, its just paired with
it in a composite view.
keep objects separate, reusable, combinable, throw-away-able,
replaceable.
(+) Optinal axis description (i.e. numbers) around 2D-sliders,
multisliderviews and envelopeviews would be great to have.
of course you could do all of this today, right now
(+) The levelmeter IMHO should have the possibility to indicate clipping
place a single LED above the fader.maybe you want a text up there
to show how much it clicked by.maybe click on it to reset it.
this is all usage, not part of the basic gui style design.
(+) I'd like to see an actual ContainerView implemented that can
have a colored outline (and optionally also a descriptive text) [2]
yes, that would be a useful general element ! (+) Please, some Radiobuttons.
true, more specifically a single round button in order to build radio buttons.
(+) A native plot window a la plot2 would be neat, also a scope
view and a freqview are IMHO needed.
those already exist. all current sc views exist.the current design
is just a rectangle with no edge styling.
as I said in another mail: maybe a raised item to contrast the
sunken item.raised has the drop shadow outside (this means scaling
the rectangle down by the size of the shadow). same light source
and angle as the sunken.
(btw. we should ask him what the angle is so we can recreate it for any future views)
with sunken and raised edge designs then many variations can be made.
a scope could appear raised, or it could be a light background color and sunken.
this would be a useful option for all/many widgets: no border /
simple curved edge / sunken / raised
a static text label could be raised giving a nice focus for that element.
a slider could use simple-curved edge, and next to it one using sunken.
cheers
Till
=felix
--- original message end ----
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Sc iss
2011-01-18 18:49:19 UTC
Permalink
btw i really like the knob design by ben. i think it's smart in the way that the color identity is preserved even if the knob is rotated to its zero position. besides the similarity to the slider2 / envelope-view handles.

----- original message --------

Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: Lucas Samaruga

2011/1/18 LFSaw <lfsaw-mvlOuy+***@public.gmane.org>
knob, however, IMHO its actual design in bens proposition looks a bit out of context to the other elements. Honestly, it reminds me of a certain circus emblem, or a barber's pole [1].
[1] http://en.wikipedia.org/wiki/Barber%27s_pole


Nope, your are really wrong, it looks like this
http://www.vectorizados.com/muestras/tiro-al-blanco-2.jpg
:-)sorry, sorry.


--- original message end ----
LFSaw
2011-01-18 19:21:58 UTC
Permalink
Post by Sc iss
btw i really like the knob design by ben. i think it's smart in the way that the color identity is preserved even if the knob is rotated to its zero position. besides the similarity to the slider2 / envelope-view handles.
I like that functionality, though I don't like its graphical implementation... but that is, of course very subjective.

cheers
Till
Post by Sc iss
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: Lucas Samaruga
knob, however, IMHO its actual design in bens proposition looks a bit out of context to the other elements. Honestly, it reminds me of a certain circus emblem, or a barber's pole [1].
[1] http://en.wikipedia.org/wiki/Barber%27s_pole
Nope, your are really wrong, it looks like this
http://www.vectorizados.com/muestras/tiro-al-blanco-2.jpg
:-)sorry, sorry.
--- original message end ----
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Lucas Samaruga
2011-01-18 19:31:35 UTC
Permalink
Post by Sc iss
Post by Sc iss
btw i really like the knob design by ben. i think it's smart in the way
that the color identity is preserved even if the knob is rotated to its zero
position. besides the similarity to the slider2 / envelope-view handles.
I like that functionality, though I don't like its graphical
implementation... but that is, of course very subjective.
Yes, isn't bad, it's just collective symbolism, which can change after this
coherent knob. Sorry, I made the same observation and I could not avoid the
obvious joke, my bad.
Post by Sc iss
cheers
Till
Post by Sc iss
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: Lucas Samaruga
knob, however, IMHO its actual design in bens proposition looks a bit out
of context to the other elements. Honestly, it reminds me of a certain
circus emblem, or a barber's pole [1].
Post by Sc iss
[1] http://en.wikipedia.org/wiki/Barber%27s_pole
Nope, your are really wrong, it looks like this
http://www.vectorizados.com/muestras/tiro-al-blanco-2.jpg
:-)sorry, sorry.
--- original message end ----
_______________________________________________
sc-dev mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Sc iss
2011-01-18 22:20:34 UTC
Permalink
maybe something like

Slider( myParent )
.orient_( \v )
.model_( myModel )
// .spec_( myModel.defaultSpec ) // this line could be omitted if this is the default behaviour
.ticks_( true )

three components, slider, model, and decorator. the decorator gets automatically chosen her
(a tick-painter derived from the spec's scaling)

best, -sciss-


----- original message --------

Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: Scott Carver<scott-y6qSm6YX8/***@public.gmane.org>

...
Post by Scott Carver
I think it's worth taking cases like that - looking at both the UI and the
code it takes to build that UI - and figuring out what will make it cleaner,
easier, more flexible, and prettier on both sides. Sciss, Felix - if you
wanted a slider with a particular range and log-scale tick marks, what
should the code/ui look like? What components would be required?
Scott Carver
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Sc iss
2011-01-18 22:10:33 UTC
Permalink
not sure there is such rule. i am an sc user who doesn't want to reinvent the wheel all the time. i don't want to design "my" LED. i prefer to have a nice configurable ready made LED that goes nicely with the rest of the look. i find other things more interesting than rebuilding basic GUI components with a user view...


----- original message --------

Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: felix
...

as a rule: SC users like to make their own things. they like their own look. that's why they use such a weird thing as SC.

-felix



--- original message end ----
felix
2011-01-18 22:35:20 UTC
Permalink
2nd rule: if anybody states there is a 1st rule someone will come along and
deny it

anarchy is complete

I have also sworn not to fuck with SC guis ever again. sigh.
but the current one keeps crashing and its wasted so much of my time with
faders disappearing.


http://soundcloud.com/crucialfelix
http://crucial-systems.com/timeblind
http://github.com/crucialfelix
Post by Sc iss
not sure there is such rule. i am an sc user who doesn't want to reinvent
the wheel all the time. i don't want to design "my" LED. i prefer to have a
nice configurable ready made LED that goes nicely with the rest of the look.
i find other things more interesting than rebuilding basic GUI components
with a user view...
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Tue, 18 Jan 2011
From: felix
...
as a rule: SC users like to make their own things. they like their own
look. that's why they use such a weird thing as SC.
-felix
--- original message end ----
ronald kuivila
2011-01-20 08:08:31 UTC
Permalink
Hi Thor,


While I see its advantages, I find the knob and circular thumb design
a bit chunky.

In thumbs, I would prefer the white perimeter to be thinner. This
would still perform
the function of differentiating the thumb from the plot but would
'feel' a bit more precise.

In knobs, I would also prefer both the white perimeter and the outer
colored ring to be thinner.
This would make the knob read more as a knob of the selected color with
the outer ring as value indicator. That is not immediately obvious in
this design.

Perhaps this means I am a visual conservative....

But the basic approach is terrific and those proportions should
probably be adjustable anyway.

Cheers,

RJK
Post by thor
Hello colliders
As many are aware of, SuperCollider is now being implemented in a
new GUI framework called Qt ( http://qt.nokia.com/ ). There was a
thread on the look of that GUI : http://www.listarc.bham.ac.uk/lists/sc-dev/msg19324.html
and we subsequently set up a dedicated project for this on the Wiki
page here: http://supercollider.sourceforge.net/wiki/index.php/GUI_Design_project
We now finally have a submitted design that is realistic and fit for
discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben
%27s_Proposition
The design of these GUI elements will be implemented in Qt and
therefore giving SC a unique look that is still minimal and neutral.
The question of native versus SC style look is something we might
want to discuss. Also it would be good if people would submit their
wish list for new widgets (or new features to existing widgets) to
be implemented.
Note that this is a sketch that will be further refined when written
in Qt and one that is put forth for the sake of discussion, not as
the final design.
So opinions, suggestions, wish list items, etc. welcome. Also, if
someone has alternative designs or wants to have a go at refining
this current design, please go ahead.
thor
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
thor
2011-01-20 10:23:49 UTC
Permalink
Hi Ron and all

I am in no business of defending the design in any way, and I
understand your
concerns. They are somewhat subjective, as you acknowledge, but I
might agree with you.

But I think the main thing is that these elements could be controlled
by the user, e.g.
- whether the thumb is circular or square
- size of the thumb and the size of the colouring within
- the thickness of the lines connecting thumbs in envelopes
- the colour values of knobs

I'm not sure if I'm projecting too much work onto the Qt designer/
programmer
but Jakob has said that there will be plenty of room to make things
user settable.

And indeed, as you mention in another mail, it would be good if this
would be factored
into the SC class so we can mess with it there.

The question is one of default values. Perhaps that's where we'll be
arguing.

On another note, I can see that this thread is now discussing MVC
strategies, but isn't that
entirely off topic? We're just discussing pixels right?

Thor
Post by paul
Hi Thor,
While I see its advantages, I find the knob and circular thumb
design a bit chunky.
In thumbs, I would prefer the white perimeter to be thinner. This
would still perform
the function of differentiating the thumb from the plot but would
'feel' a bit more precise.
In knobs, I would also prefer both the white perimeter and the outer
colored ring to be thinner.
This would make the knob read more as a knob of the selected color with
the outer ring as value indicator. That is not immediately obvious
in this design.
Perhaps this means I am a visual conservative....
But the basic approach is terrific and those proportions should
probably be adjustable anyway.
Cheers,
RJK
Post by thor
Hello colliders
As many are aware of, SuperCollider is now being implemented in a
new GUI framework called Qt ( http://qt.nokia.com/ ). There was a
thread on the look of that GUI : http://www.listarc.bham.ac.uk/lists/sc-dev/msg19324.html
and we subsequently set up a dedicated project for this on the
Wiki page here: http://supercollider.sourceforge.net/wiki/index.php/GUI_Design_project
We now finally have a submitted design that is realistic and fit
for discussion on the lists.
http://supercollider.sourceforge.net/wiki/index.php/Ben%27s_Proposition
The design of these GUI elements will be implemented in Qt and
therefore giving SC a unique look that is still minimal and
neutral. The question of native versus SC style look is something
we might want to discuss. Also it would be good if people would
submit their wish list for new widgets (or new features to existing
widgets) to be implemented.
Note that this is a sketch that will be further refined when
written in Qt and one that is put forth for the sake of discussion,
not as the final design.
So opinions, suggestions, wish list items, etc. welcome. Also, if
someone has alternative designs or wants to have a go at refining
this current design, please go ahead.
thor
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Sc iss
2011-01-20 14:30:52 UTC
Permalink
when done thoroughly, a controller-view, such as a widget, would, when used as controller, not directly update its view but just the model. for instantaneous visual feedback it is crucial then that the view is notified immediately. i don't know how you would do this in a poll-only model. it is also an open question if polling is really less intense, as you need to do it all the time to find out if anything changed. your first point is correct, but the last one not. the model is essentially timeless. if views want to be more efficient, they can easily use something like swingOSC's Collapse to relax the needs to update views at a too fast pace.

you can think of more scenarios, where keeping an observer list is crucial. for example observers could have the role of vetoing a value change. etc.

there are more complex models than just scalar value representations. for example a list or a tree -- you don't want the observers to traverse all the time the whole data structure to find out, if a node has been inserted or not. a text document is an example, too, where characters are inserted etc., and the information _where_ something in the model changed is merely contained in the update notication, not in the model data (the text).

best, -sciss-


----- original message --------

Subject: Re: [sc-dev] GUI Design Project
Sent: Thu, 20 Jan 2011
From: Julian Rohrhuber<rohrhuber-***@public.gmane.org>
[..]
Post by Julian Rohrhuber
Done properly, polling allows objects to be more completely uncoupled than
* there is no need to implement an interface for it in the model: anything
can be a model as is.
* the model doesn't need a set of all other objects interested in it, but
those who are interested know what they need.
* timing needs not be controlled by the model: it is not presupposed that a
certain change matters to a view, but the view looks it up
[...]
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Andrea Valle
2011-01-20 14:44:31 UTC
Permalink
In my fairly modest experience, I've used MVC for 1. precise on-time mirroring and 2. non-temporally-dense updating.
Polling has been useful when 1. a regular updating policy was in need/possible and 2. when a max updating
rate was mandatory.
So, I tend to consider the two strategies as appropriate for different contexts.
E.g.
- pressing a button typically requires fast reply, triggered by event (MVC).
- turning a knob on a GUI controller can generate great message traffic on MVC, I'd prefer polling.
(my best case was a MIDI controller with knobs sending msgs to Arduino over the serial port. MVC
was causing a lot of traffic, freezing the whole stuff....Polling allowed me to control the max rate.
Evidently I paid the cost of a constant CPU use)

just 2c

Best
-a-
Post by Sc iss
when done thoroughly, a controller-view, such as a widget, would, when used as controller, not directly update its view but just the model. for instantaneous visual feedback it is crucial then that the view is notified immediately. i don't know how you would do this in a poll-only model. it is also an open question if polling is really less intense, as you need to do it all the time to find out if anything changed. your first point is correct, but the last one not. the model is essentially timeless. if views want to be more efficient, they can easily use something like swingOSC's Collapse to relax the needs to update views at a too fast pace.
you can think of more scenarios, where keeping an observer list is crucial. for example observers could have the role of vetoing a value change. etc.
there are more complex models than just scalar value representations. for example a list or a tree -- you don't want the observers to traverse all the time the whole data structure to find out, if a node has been inserted or not. a text document is an example, too, where characters are inserted etc., and the information _where_ something in the model changed is merely contained in the update notication, not in the model data (the text).
best, -sciss-
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Thu, 20 Jan 2011
[..]
Post by Julian Rohrhuber
Done properly, polling allows objects to be more completely uncoupled than
* there is no need to implement an interface for it in the model: anything
can be a model as is.
* the model doesn't need a set of all other objects interested in it, but
those who are interested know what they need.
* timing needs not be controlled by the model: it is not presupposed that a
certain change matters to a view, but the view looks it up
[...]
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Miguel Negrao
2011-01-20 14:53:27 UTC
Permalink
At least for the case of guis updating too often, someone talked some time ago about views that have a max update rate, so if something is sent at a too high rate, it will just accept one value per time window.

best,
Miguel Negrão
Post by Andrea Valle
In my fairly modest experience, I've used MVC for 1. precise on-time mirroring and 2. non-temporally-dense updating.
Polling has been useful when 1. a regular updating policy was in need/possible and 2. when a max updating
rate was mandatory.
So, I tend to consider the two strategies as appropriate for different contexts.
E.g.
- pressing a button typically requires fast reply, triggered by event (MVC).
- turning a knob on a GUI controller can generate great message traffic on MVC, I'd prefer polling.
(my best case was a MIDI controller with knobs sending msgs to Arduino over the serial port. MVC
was causing a lot of traffic, freezing the whole stuff....Polling allowed me to control the max rate.
Evidently I paid the cost of a constant CPU use)
just 2c
Best
-a-
Post by Sc iss
when done thoroughly, a controller-view, such as a widget, would, when used as controller, not directly update its view but just the model. for instantaneous visual feedback it is crucial then that the view is notified immediately. i don't know how you would do this in a poll-only model. it is also an open question if polling is really less intense, as you need to do it all the time to find out if anything changed. your first point is correct, but the last one not. the model is essentially timeless. if views want to be more efficient, they can easily use something like swingOSC's Collapse to relax the needs to update views at a too fast pace.
you can think of more scenarios, where keeping an observer list is crucial. for example observers could have the role of vetoing a value change. etc.
there are more complex models than just scalar value representations. for example a list or a tree -- you don't want the observers to traverse all the time the whole data structure to find out, if a node has been inserted or not. a text document is an example, too, where characters are inserted etc., and the information _where_ something in the model changed is merely contained in the update notication, not in the model data (the text).
best, -sciss-
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Thu, 20 Jan 2011
[..]
Post by Julian Rohrhuber
Done properly, polling allows objects to be more completely uncoupled than
* there is no need to implement an interface for it in the model: anything
can be a model as is.
* the model doesn't need a set of all other objects interested in it, but
those who are interested know what they need.
* timing needs not be controlled by the model: it is not presupposed that a
certain change matters to a view, but the view looks it up
[...]
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
Scott Carver
2011-01-20 19:59:59 UTC
Permalink
All of the mentioned paradigms are useful (i.e. direct connections, polling, top level notifiers). Given the other ongoing thread about a UI designer, I think the challenge is to easily and flexibly allow users to:
- Design a UI in a designer (or programmatically, or in the deep, custom, pixel-pushing way some of us love)
- Get values from your midi device
- Get external OSC messages
- Build a synth or environment with many synths & buses

And then connect these worlds in a modular way,
- without needing heavy modification of any already existing objects (i.e. I don't want to have to touch my ui code to add a midi controller)
- with the ability to specify the type of connection (i.e. push, pull) and throttling/rate limiting
- with easy cleanup (i.e. not leaky) and not too many unnecessary objects to keep track of

It's worth looking at how other languages / API's do similar things.

In C++, with boost::signals, something like:

Slider::SetModel(Model model)
{
valueConnection = model->ValueChangedSignal.connect( bind(&Slider::SetValue, this, _1) );
}

In C++, using QT, ala:
connect(&model, SIGNAL(valueChanged(float)), &slider, SLOT(setValue(float)));

In Flex, something like:
[Bindable] var model:ControlValue = 0.0;
...
<mx:Slider value="{model}" />

or:
<mx:ControlValue id="myValue" value="0.0" spec="..." />
<mx:Slider id="mySlider" />
<mx:Binding source="myValue" destination="mySlider" twoWay="true" />


In SC, from stock parts:
slider = Slider(w, Rect(...));
model = Ref(0.0);
slider.action = {
| view |
model.value = view.value;
model.changed(view.value);
};
updateSliderFunc = {
| model |
slider.value = model.value;
};
model.addDependent( updateSliderFunc );
slider.onClose = {
model.removeDependent( updateSliderFunc );
};

with Ron's CV:
slider = Slider(w, Rect(...));
model = CV(\freq);
model.connect(slider);

Of the examples, the SC ones have the most possibility of bugs - if slider.onClose or slider.action get changed at any point down the road, your connections will be broken. Ron's CV stuff is very good though - expanding that into a more general model for connecting views and data would be promising. In the C++, Flex, and CV cases, all cleanup is automatic. Flex makes two-way connections quite easy, also (though that's not always a good paradigm).

Scott Carver
Post by Miguel Negrao
At least for the case of guis updating too often, someone talked some time ago about views that have a max update rate, so if something is sent at a too high rate, it will just accept one value per time window.
best,
Miguel Negrão
Post by Andrea Valle
In my fairly modest experience, I've used MVC for 1. precise on-time mirroring and 2. non-temporally-dense updating.
Polling has been useful when 1. a regular updating policy was in need/possible and 2. when a max updating
rate was mandatory.
So, I tend to consider the two strategies as appropriate for different contexts.
E.g.
- pressing a button typically requires fast reply, triggered by event (MVC).
- turning a knob on a GUI controller can generate great message traffic on MVC, I'd prefer polling.
(my best case was a MIDI controller with knobs sending msgs to Arduino over the serial port. MVC
was causing a lot of traffic, freezing the whole stuff....Polling allowed me to control the max rate.
Evidently I paid the cost of a constant CPU use)
just 2c
Best
-a-
Post by Sc iss
when done thoroughly, a controller-view, such as a widget, would, when used as controller, not directly update its view but just the model. for instantaneous visual feedback it is crucial then that the view is notified immediately. i don't know how you would do this in a poll-only model. it is also an open question if polling is really less intense, as you need to do it all the time to find out if anything changed. your first point is correct, but the last one not. the model is essentially timeless. if views want to be more efficient, they can easily use something like swingOSC's Collapse to relax the needs to update views at a too fast pace.
you can think of more scenarios, where keeping an observer list is crucial. for example observers could have the role of vetoing a value change. etc.
there are more complex models than just scalar value representations. for example a list or a tree -- you don't want the observers to traverse all the time the whole data structure to find out, if a node has been inserted or not. a text document is an example, too, where characters are inserted etc., and the information _where_ something in the model changed is merely contained in the update notication, not in the model data (the text).
best, -sciss-
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Thu, 20 Jan 2011
[..]
Post by Julian Rohrhuber
Done properly, polling allows objects to be more completely uncoupled than
* there is no need to implement an interface for it in the model: anything
can be a model as is.
* the model doesn't need a set of all other objects interested in it, but
those who are interested know what they need.
* timing needs not be controlled by the model: it is not presupposed that a
certain change matters to a view, but the view looks it up
[...]
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
Miguel Negrao
2011-01-21 10:07:13 UTC
Permalink
Post by Scott Carver
- Design a UI in a designer (or programmatically, or in the deep, custom, pixel-pushing way some of us love)
- Get values from your midi device
- Get external OSC messages
- Build a synth or environment with many synths & buses
And then connect these worlds in a modular way,
- without needing heavy modification of any already existing objects (i.e. I don't want to have to touch my ui code to add a midi controller)
- with the ability to specify the type of connection (i.e. push, pull) and throttling/rate limiting
- with easy cleanup (i.e. not leaky) and not too many unnecessary objects to keep track of
It's worth looking at how other languages / API's do similar things.
In Cocoa bindings:

[joystick bind:@"angle" toObject:GraphicController withKeyPath:@"selection.shadowAngle" options:options];

see: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html#//apple_ref/doc/uid/20002373-CJBEJBHH

For SC I do it like this:

I use the class Binding that I created. With this class the syntax becomes quite compact, it’s a two update mechanism that prevents loops (slider updating model, model updates slider, and so forth... ).

(
w = FlowView.new;
~slider = Slider(w,***@20).action_({ |obj| obj.changed });
~model = Ref(0.5);
Binding(~model,~slider1);
)
~model.value_(0.2).changed

off course, the syntax could be made more sugary to:
(
w = FlowView.new;
~slider = Slider(w,***@20).action_({ |obj| obj.changed });
~model = Ref(0.5);
~model.bind(~slider1);
)

If the default action was obj.changed then it would be even more compact. I
(
w = FlowView.new;
~slider = Slider(w,***@20);
~model = Ref(0.5);
~model.bind(~slider1);
)


With Updater it’s a bit more work
(
w = FlowView.new;
~slider = Slider(w,***@20).action_({ |obj| ~model.value = obj.value });
~model = Ref(0.5);
Updater(~model,{ |model| ~slider.value = model.value })
)

~model.value_(0.2).changed
--
Miguel Negrão // ZLB
http://www.friendlyvirus.org/artists/zlb/
Jonatan Liljedahl
2011-01-31 17:50:13 UTC
Permalink
I usually use an interval timer that updates the GUI if a flag is set,
and this flag gets set by some user-action callback or if something else
happens that needs to be reflected in the GUI. Then one can have
different timers for different parts, while some user actions might
change another part of the GUI directly, without any timer.

/Jonatan
Post by Andrea Valle
In my fairly modest experience, I've used MVC for 1. precise on-time mirroring and 2. non-temporally-dense updating.
Polling has been useful when 1. a regular updating policy was in need/possible and 2. when a max updating
rate was mandatory.
So, I tend to consider the two strategies as appropriate for different contexts.
E.g.
- pressing a button typically requires fast reply, triggered by event (MVC).
- turning a knob on a GUI controller can generate great message traffic on MVC, I'd prefer polling.
(my best case was a MIDI controller with knobs sending msgs to Arduino over the serial port. MVC
was causing a lot of traffic, freezing the whole stuff....Polling allowed me to control the max rate.
Evidently I paid the cost of a constant CPU use)
just 2c
Best
-a-
Post by Sc iss
when done thoroughly, a controller-view, such as a widget, would, when used as controller, not directly update its view but just the model. for instantaneous visual feedback it is crucial then that the view is notified immediately. i don't know how you would do this in a poll-only model. it is also an open question if polling is really less intense, as you need to do it all the time to find out if anything changed. your first point is correct, but the last one not. the model is essentially timeless. if views want to be more efficient, they can easily use something like swingOSC's Collapse to relax the needs to update views at a too fast pace.
you can think of more scenarios, where keeping an observer list is crucial. for example observers could have the role of vetoing a value change. etc.
there are more complex models than just scalar value representations. for example a list or a tree -- you don't want the observers to traverse all the time the whole data structure to find out, if a node has been inserted or not. a text document is an example, too, where characters are inserted etc., and the information _where_ something in the model changed is merely contained in the update notication, not in the model data (the text).
best, -sciss-
----- original message --------
Subject: Re: [sc-dev] GUI Design Project
Sent: Thu, 20 Jan 2011
[..]
Post by Julian Rohrhuber
Done properly, polling allows objects to be more completely uncoupled than
* there is no need to implement an interface for it in the model: anything
can be a model as is.
* the model doesn't need a set of all other objects interested in it, but
those who are interested know what they need.
* timing needs not be controlled by the model: it is not presupposed that a
certain change matters to a view, but the view looks it up
[...]
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Scott Carver
2011-05-11 00:32:51 UTC
Permalink
What's the status of the GUI design project?

- Scott Carver

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
LFSaw
2011-05-11 09:11:23 UTC
Permalink
gooood question...

:-)
Till
Post by Scott Carver
What's the status of the GUI design project?
- Scott Carver
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Jakob Leben
2011-05-11 09:28:11 UTC
Permalink
Post by Scott Carver
What's the status of the GUI design project?
I've got some very early code that partially implements a cross-design
picking from both two proposals. I've got stuck a bit with implementing the
style for Qt's pre-existing widgets like combo box (pop up menu) and list
view - those will be more difficult cuz I need to figure out exactly where
to insert all the necessary code to override Qt's styling.

Btw, there will have to be some changes to proposals done, because it turned
out they don't scale well: Ben's proposal has troubles with small widget
sizes, and Jonka's proposal has troubles with other color schemes than his
proposed one.

I'll try to make a branch of my work up to date ready so you can test it.

Cheers

Continue reading on narkive:
Loading...