what makes a good [screen] interface?

  • monome team wants to know our thoughts.

    what should be done with aleph's OLED?

  • @gli: cheersmate

    this is probably most useful in the specifics of screen-based UI. how can we best communicate relevant information in a performance setting? what information do you want to see? what is the best way to communicate that 'type' of information?

    to contextualise - there already exists the BIGNUM and SCREEN operators that are very basic in displaying particular parameters, or arbitrary screen drawing. we've spoken about adding some kind of bar graph to display parameters more arbitrarily than a simple number. obviously these are super basic and much, much more is possible, so tell us your thoughts and ideas.

  • "Signal meters" that display an actual db threshhold w/ a peak would be useful and serve an aesthitic/feedback purpose. These could take on numerous designs (vintage VU style, vertical bar, horizontal bar, etc)

  • i will have to really think about this but i think the EDIT mode is fine

    probably the wrong person to ask...the instruments i gravitate toward can be played without looking at them. my eyes are closed 90% of the time when i drum and i carried that habit over to electronics/wiggling

    so even if a device has a screen (e.g. SP 404)
    i never use it

  • I find it's about knowing an instruments workflow. For example: (for my sins, god love Akai) I purchased the MPC Renaissance and being used to their products I found that having to use software in conjunction with the hardware was annoying. I can use an MPC from the screen and it's minimal information on screen is concise and well thought out. So being used to a workflow is key I find. Eg, with my 256 grid the apps that I am familiar with requires very little usage of a screen layout and more time to engage with the hardware.
    Not sure anything there is remotely useful, just my 10c worth.

  • the only screened device that i have used with any frequency were the various incarnations of the shruthi synths, and the sammich synths. Both had 16 * 2 LCD displays, 5 buttons, 5 knobs. So in the controls respect, quite similar to the aleph.

    Shruthis for the most part avoided sub menus. Which worked very well. each button represented a menu, with each knob having a different function on each menu. Which meant that you could quickly get to know the interface, and only needed to look when you wanted to fine tune. Where it fell down IMO, was in the mod matrix, where i quickly got lost paging through 3 letter acronyms trying to remember what each acronym represented. there was also no real visual way of seeing what operator was tied to what in the mod matrix.

    The sammiches (SID and FM) both had an utterly cruddy UI that caused me to part with both after a very frustrating time with it - they were unprogrammable without the computer editor, and that was completely flaky. also masses of sub menus and acronyms.

    it might be against the aleph philosophy, but i'd like to see similar functions behind the same buttons and knobs across the scenes/apps (not sure if that is the right lingo), with key UI controls, meters and design objects made available for use for all developers - a "UI spec" if you will. i'd also like to as few as possible sub menus.

    I think a "performance" view like max have implemented would be pretty awesome. where you could expose the most important controls by default and the toggle to the entire list in the text view on the aleph if required.

    i say all this and i don't even have the thing. i'm saving my pennies though :)

  • the jazzmutant lemur is a good screen gui. 4 buttons at the top and a library of touchscreen objects which can be dynamically generated and scripted into interesting controllers. a bouncing ball may represent a signals position in a circular panning system.

    objects like button, multislider, toggle, scope~, gain~ in max/msp are useful on screen when they serve as guides. perhaps a group of oscillators is 'muted' and multisliders serve as a frequency ratio chart to monitor the state of signals before mixing them in.

    screen gui elements that exist closest to the 'performance dynamics' are great, the kinds that help one lose some sense of time.

    how is the planned 'visual editor' is going to factor into the equation?

  • edited the OP

    yes, this is regarding screen-based UI for aleph development

    @raja now that you mention it we could hijack this thread and talk about the editor too

    on CDM @tehn used the nord modular app as a point of comparison (for the bees browser/editor)

  • there aren't any sub-menus in bees, btw.. well, unless you count the top-level list of pages as a "menu."

  • I for one, would love to see some kind of gui. Bars or blocks representing numeric values? I dunno, the oled screen seems a potential source of useful information, better to make it as user friendly as possible than to ignore it IMHO.

  • As a vim user I say: more modes!

  • @all are talking about the EDIT mode? or PLAY?

    i am curious

  • i think y'all are on the right track, but @karaokaze is right to remind himself we're talking about monome here! ie. whatever it is, it's going to be minimal.

    if i could suggest, i'd say this thread should be about the specifics of what that could mean. so far all we've got is 'one number display that changes' and a 'bar graph'.

    the 'signal meters' mentioned up top are by their nature very difficult! it would require some kind of bi-directional communication between the DSP and bees that takes up bandwidth and processing power. @eos can you have example situations where you need to see this kind of display? the main outputs have an analog level indicator, but what kind of internal routings are useful to be displayed? (keep in mind i have no idea how possible this is re: coding).

    @gli this is 100% about PLAY mode i believe.

  • @galapagoose ok i thought PLAY is what the discussion was focused on

    as i said earlier, EDIT is fine in my opinion.

  • someone could make BARS in an hour or so!

    @jah modal density is necessary! lots of it in bees menus, both momentary (hold button and turn) and persistent (which page). edit/play is practically identical to the vim model.

    as far as modal behavior in PLAY mode, this is acheived by creating multiple graphics objects and governing their ENABLE values with presets. same presets would also be governing encoder/sw output routing.

    can then select among presets in a manner analogous to the "coarse/fine" mode switching of an encoder in the first preset tutorial.

  • @zebra it may have been touched on in another thread but i have a question: what level of access do we have to the screen?

    is it only accessible thru C programming? or does control lie in the realm of BEES and operators?

    i would love to make/tweak the UI elements to suit my fancy

    edit :: never mind...i just saw the entry on bees' ops page

  • galapagoose wrote: "@karaokaze is right to remind himself..."
    Ha! ^this is the best way I've ever seen it put what I actually do around here ;)

  • @galapagoose what would be most useful to me is an indication of where i am in relation to MIN MAX values

    numbers are fine but i'd prefer an empty/full box when switches are toggled

    and shaded pies for the encoders

    just basics

  • not an aleph owner yet but curious to how it evolves so i'll chime in :)

    as an op-1 fan i have to agree that some screens don't add a lot in terms of clear feedback (though they look great), but there are some really nice simple ones that could well be relevant, for example...
    mixer: http://goo.gl/djm0aY
    eq: http://goo.gl/L3cZKh
    delay: http://goo.gl/l4tfbX

    could also be good to think about what are the most useful max4l UI bits as a starting point...
    eg 1: http://i.imgur.com/0H76Y2j.png
    eg 2: http://i.imgur.com/8mPswRH.png

  • @galapagoose: I'm colorblind, so I have difficulties picking up the subtleties of whatever is going on with the gradiation of input/output LEDs. What happens when your signal is clipping? Do they go red? Or is solid pink just a loose representation of full signal?

    Anyway, that's where I'm coming from. Just thinking of a simple representation of input/output signals so I can see the relationship to the threshold/ceiling.

    Something along these lines comes to mind (but even more minimal?)

  • http://instagram.com/p/k3X4n_OpKv/

    Just sketching some ideas for a granular looper interface.
    Even I think this is to busy. Keep It Simple Stupid.

  • the signal level indicators on the aleph basically have 2 leds behind each. the white led is a simple level meter that hits maximum brightness around the time the red led starts to turn on. the threshold where the red comes on is probably ~6dB or so below where digital clipping occurs (on the inputs). you'll see quite a strong pinkish hue before things start to clip the digitals.

    i'm embarrased to say i don't really understand colour blindness much at all – always thought it was just about red and green appearing very similar...

    will definitely think about how to implement a sort of level meter, though i doubt it will reach the top of the list for a while – it's one of the few UI elements that requires some serious backend problem solving.

    i've always operated on the 'if it sounds good, it is good' mantra, but i appreciate this isn't everybody's cup of tea!

  • I'm colorblind and never noticed it went pink. Think of colorblindness as a loss of saturation. We can usually adjust to dark environments quicker and see values a lot better.

    Does the OLED screen have color?

  • ahhh that's super interesting (and a great explanation, thanks!)

    the OLED is white! indeed the only element on the whole aleph that isn't a shade of grey are those little red clip indicators. the effect is subtle as the white leds are much brighter than the reds, but it is an interesting threshold display..

  • what ezra said-- BARS is on our short list given it's so easy.

    has anybody tried making something whacky with SCREEN?

  • snow day where i live @tehn

    i'll try some stuff w/ screen in a few minutes

  • I would love to first see the text stop scrolling, Can we some way make the visual feedback sit on their own lines and just refresh the numbers instead of scrolling like a console?

  • @c1t1zen
    you should set the params to 'HIDE' in the INPUTS page (to hide them in play mode), then use BIGNUM to display the ones you want to see. an interim solution, but it wills stop the scrolling and still provide data.

    actually you probably don't need to set the params to HIDE at all. just make some BIGNUMs and enable them to take over the screen.

  • thanks for the info, I'll try out those ideas.

  • I think situational awareness as a frame for the screen and in the center a mode open. You can dial around the modes bring up focused controls.

  • BIGNUM is fun, gonna work on a scene with that.

    Can I get a BIGWORD?

  • Would be happy with two-four letters :)


  • @dimi3
    could you elaborate on 'situational awareness'? sounds intriguing but i don't know what it means! links perhaps?

  • it is a term for what is going on in my environment. So some thing like what is linked to what, values, states and mode. these data points location never move, ie if knob data is the bottom edge of the screen you always see data about the knobs at the bottom of the screen.

    Good UI is about consistency just as much as anything else.

    I will try a wire frame something up.

  • @dimi3 i think i get what you mean, but a more fleshed out example would be helpful. is it specifically a spatial thing? could the op1's colour coding be said to do the same thing (ie. red knob is always linked to red UI), and if so, is it just a very clear 'key' that you're looking for?

    i'm mainly asking because bees is a pretty flexible beast and can be used for a very large number of functions. as such sometimes the knobs will be the most important (eg. delay time & oscillator pitch), other times they might be more abstract (eg. moving the x&y pointer in a grid), and still others might not need them at all..

    i think the biggest challenge of designing UI for the aleph comes from this flexibility. that's why systems like max have generic objects that you can move around, but this seems to be outside of your desired interface style.

    i agree that creating a sort of 'language' of communication from UI to user is incredibly important – hence this thread – but of course we're limited to 128x64 pixel greyscale screen! all these thoughts & ideas are really useful!

    @c1t1zen: BIGWORD could probably be done. how would you go about setting the state of the word though? would it be to show param names, or toggle states or note names, or something else entirely?

  • Toggle state would probably be most useful.
    One reason is I would like to do a label so a static state is fine for now.
    Toggle would be helpful for something like 'on' or 'off' states but I guess a simple '0' or '1' is fine for that.
    I'm really enjoying the BIGNUM so far and using it with encoders, but is there a way to remove all the black to the left of it? I suppose this is for giant numbers. But I'm looking to only really use 3 digits max.
    Trying to understand SCREEN more and why all the flashing and trace lines!? heh

  • http://instagram.com/p/k_hdQtupJz/

    BIGNUM axis #s

    ENC0 x 00 y 00
    ENC1 x 00 y 32
    ENC2 x 64 y 00
    ENC3 x 64 y 32

  • well, there are no message types in bees, only integers, so it's hard to see how a generic string display would be usable; what would you send it? raw ascii character codes?

    i would propose a dedicated PRESET_NAME , or whatever, that just shows preset name all huge for a given index. i would use that a lot.

    i would also propose a PARAM_VALUE , or whatever, that shows and scaled param value and unit all huge. would take a value, and an index for the parameter type. or maybe index for specific param in current list, so the label can come up too.

  • btw, and @gli, i should point out that the SCREEN operator is probably not super useful / efficient as a way to build most GUIs. but sometimes a really super minimal or weird thing is nice, like one pane of color, 'hearbeat' graph, i dunno. ( i would like to add a ZOOM input that just blows up each pixel to 2x2, 3x3, etc, and crops to the upper left corner. then you would hardly need a separate BARS. )

    copying and hacking op_screen source would be an excellent way to make a new display operator. the raw screen interface is a little weird (there are reasons) but hopefully not actually hard to read/use. SCREEN/BIGNUM are just examples showing the 'right' way to access the screen; op maintains its own pixel buffer, owns a 'region' object pointing to it, uses the rendering functions on the region, and periodically sends the region to the screen driver if data has changed. (a 'region' basically manages any arbitrarily-sized and -positioned rectangular chunk of pixel data.)

    @eos , @galapagoose , re:metering: well actually it's very easy for bfin to report param values back to bees. this happens after loading a new DSP module, for example. but the idea is to add parameters that just contain analysis results, and a POLL operator or whatever; the framework is there. making a fancy dB meter probably wouldn't be my first application of this, but certainly not hard either.

    i'm a tiny bit confused by this thread. if it's about bees, then it's about what kind of rendering operators would be useful as toolkit components. which is not really the same as actually designing a good UI - that of course depends on the actual instrument you're trying to make, what kind of control, etc. in bees, these can be dynamic decisions. maybe there are consistent 'template' UI models that are universally useful. i'd like to see different tries at that in the form of big operators, though at some point i think it becomes easier just to code the whole thing in C, when interactions between modes / states / inputs / pixels become very complex and history-dependent - at which point a developer should consider forking bees and replacing the whole PLAY mode module with their own jam, defining handler functions directly.

    anyways.... small static number fields would be good. small static string fields would be good too; there's that thing of how to edit their contents though. operator-specific subpages are a general solution to that kind of problem, that has been on the table for a long time. a pain to implement but it should be done eventually.

  • well, i took poetic license
    it was a logical continuation from another (unrelated) thread

    even tho only @galapagoose asked, i think the feedback will benefit anyone designing the UI for their scene

    still probably best if we each create what we personally need

  • @zebra PRESET_NAME or PARAM_VALUE would be fine. If you look at the instagram video I posted I was able to use BIGNUM well but it would be easier to have a label with those numbers. I could then load up different scenes and know immediately what does what.
    Scaling the BIGNUM and other visual ops would be super useful. I can only fit four BIGNUMS into a screen neatly and I would love to make labels still at the bottom for each SW.

  • yooo -- yeah i guess my intention here was to get some high level feedback about what people want to see us work on over the next months. not so much 'i need this specific OP' -> that would belong better on the feature requests thread.

    while obviously more complex structures could have a c coding element, it would be nice to provide a few screen interfaces, or elements, and i thought people might have ideas about what does and doesn't work in their process.

  • I dunno if this is relevant but I always liked to see graphical representations of modulation amount and speed. I think the aalto has this as well as massive and faw circle if I'm not mistaken. The attached photo demonstrates this from massive. The level knob shows bipolar modulation and the release, unipolar. I think aalto goes a step further by animating the position.

    Of course I don't have any of these on my modular and get by fine so who knows.

    294 x 151 - 27K
  • can't scale the BIGNUMs. it is an anti-aliased font that actually took pretty enormous pains to make. but can of course add a small NUM that uses the 1-bit "system font."

  • Cool. I find the regular font on the screen to small. Something between the two sizes would be great. Is it possible to scale with the 1-bit font?
    Thanks for all the info zebra.

    I'm looking to make something like this: http://instagram.com/p/lGDAeaOpHX/

    Moved this request to.

  • well, it's easy to just blow up a font by a factor of 2 and make it chunkier, but that doesn't get you much. anything else is gonna be weird to code, and weird looking too.

    the system font uses a very memory-efficient bitwise column encoding. it can be seen at aleph/avr32_lib/src/font.c. if someone wanted to make an additional or alternative 1bit font, they would be best served by following this format and making additional functions to access the alternative font.

    the anti-aliased font is a little more arbitrary. i made a whole horrible little ecosystem of scripts (c and freakin scheme) in aleph/utils/bmp , which can actually generate bitmap sources for an arbitrary font by running it through GIMP... and producing .xpm as an intermediate step, ugh... it's pretty insane but it does work, and i tried out several fonts before settling on the one you see in BIGNUM. this is a 30pt font with each glyph cropped to 9x19 px.

    in case someone wants to replace the default AA font or add an alternative, i've tried to keep that possibility open (if, unfortunately, kind of circuitous.) check out the readme.txt in aleph/utils/bmp, and also take a look at the existing font sources in aleph/avr32_lib/src/fonts.

  • I'll look into those. Thanks.
    That does seem like a process to create fonts, but if it's still possible, I'll try to give it a shot. Sorry to be such a pest.