I'm sure UI development is an on-going process, but I have a few general ideas I thought I might share.

One, the visuals should be completely independant of the music source, so that they operate for the tuner, aux and empeg audio outs exactly the same. Basically, as a background process that has nothing to do with the source. That would make things nice and consistant.

Two, have the information display have three modes: Off, On for X amount of time at begining of track, and On all the time. Also make this consistant between all three audio modes, for consistancy. I personally would use just the second mode of operation, although the other two would be handy depending on situations.

Third, you can make the menu smaller by getting rid of the bounding lines and moving it to the top of the display, and only using the small font. Maintain the scrolling (or have a "Config" menu option that allows people to configure various things including scrolling) and you can have a drop-down menu for multiple-choice items, like information display.

For Playlists, you could do what you do now and replace the menu bar with the playlist names and have sub-playlists appear on the drop-down menu.

I would also avoid using that "small font to large when selected" and just go with the inverse - this saves space on the relatively small display for longer drop-down menus.

If you like, I can draw up my suggestions in a nice GIF image to illustrate what I mean.

As an aside, if you want to see various ways to do fonts and graphics on the display, I suggest you make a trip to your local arcade and take a look at a pinball machine or two - modern pinball machines use a DMD which is *exactly* the dimensions and bit-depth as the empeg unit, offering an excellent source for ideas and techniques. :)

As an aside, if you want to see various ways to do fonts and graphics on the display, I suggest you make a trip to your local arcade and take a look at a pinball machine or two - modern pinball machines use a DMD which is *exactly* the dimensions and bit-depth as the empeg unit, offering an excellent source for ideas and techniques. :)

I don't think suggesting that the Empeg Developers should
go to the local pub to look at the PinBall machine is a
particularly good idea - we have enough trouble
getting them out to do any work in the first place!

Paul

>One, the visuals should be completely independant of the music source, so that
>they operate for the tuner, aux and empeg audio outs exactly the same.
>Basically, as a background process that has nothing to do with the source.
>That would make things nice and consistant.
Hmm i guess most of the visuals take direct benefit from the fact that the mp3 engine has the spectrum analysis ready without more work to do ...
That would mean: to do so for radio and aux, the empeg must do a fft to also do the visuals, so it really depends where the music comes from.
As it is for example also more cpu load to compress to mp3 as it is to decompress it, i have no idea, if the arm is strong enough :) to do the fft for doing the visuals likewise for aux and radio, empeg ppl, what do you think ?



>Two, have the information display have three modes: Off, On for X amount of
>time at begining of track, and On all the time.

YESYESYES ...
I hate the fact that you can't see the visuals corectly when the info is on, so having it on for the first X second would be great and not too hard to do.
Something also beeing useful, but a bit harder to do is:
When info is on -> compress the visuals in the top lines -> so the info is not just on top of the visual, but the visual gets "scaled" to fit in the leftover lines ( 24 ?? )


>Third, you can make the menu smaller by getting rid of the bounding lines and
>moving it to the top of the display, and only using the small font.

You speak out my thoughts

>Maintain the scrolling .... blablabla :)
Get rid of it in first place, a gui should be fast in first place, fancy in second, not vice versa ( speaking as the mother of wisdom, doing GUI's :)


>For Playlists, you could do what you do now and replace the menu bar with the
>playlist names and have sub-playlists appear on the drop-down menu.

Another -> GO FOR IT from my side :)

Yep Yep, so i mostly agree with you, NG ...
empeg, hear the people speaking :)



Nils

P.S. But please Do that hierarchical playlists first, please, i got the smallest setup -> 4GB and it already sux big time ... Forget that PIN crap :)

P.S.S. EQ for front & back seperated !! :) ( as third place or so, after the updated gui )

..actually we have our own pinball machine (Bugs Bunnys Birthday Ball) in our relaxing/brain storming area :-)

It doesn't have the matrix display though!

Just to clear this up once & for all :)

The visuals *cannot* work on the radio/aux, as the sound is within the DSP and not the StrongARM - we have no access to the audio data apart from the MP3, which we generate ourselves and run the visuals on as it gets put into the sound buffer.

Sorry!

Hugo

That's unfortunate.

They may not be able to *react* to hte music, but having some of them *visible* would be good, as some are interesting even when there's no music. Like the cube, or the wireforms, or the checkerboard.

Better than a blank display.

Although I am wholly ignorant of the architecture of the system, it seems to me that there is still some scope here for visuals attached to the AUX/RADIO inputs of the empeg. I assume that the visuals run as a stand-alone module which has some form of input from the MP3 data-processing chain to give them their activity.

Some of the visuals are static images that transform in some way as the input is applied (the large scrolling track info + starfield, bounce box, checkerboard, etc.) Some others rely totally on the input to operate (the oscilloscope, spectrum analysers, Lissajous figures, etc.). This second group, without input, would be very static and pretty worthless. However, the first group would still continue to display without input activity, and hence would be candidates for use with the AUX/RADIO inputs, no matter how "static" they would look. I for one would not object to this, if it could be achieved some way.

Part of the problem of suggesting this (after Hugo has explained) is that I am making the suggestion in absence of knowledge of the architecture of the box h/w, or the signal processing path within the software. For example, is there a switched output stage with three inputs to it (radio, aux, mp3) with the mp3 output coming from a DAC? Where is the activity information fed to the visuals? Are the visuals actually seperate from the mp3 player, or a part of it?

Hugo, would it be possible (without releasing too much commercially sensitive info) to produce a simple block diagram of the hardware and software architecture to give us an idea? Of course, if this is inappropriate, we'll have to like it and lump it... ;^)

In a previous post, one of the empeg team mentioned that AUX input is digitized, put through the DSP, then back out the DAC to the outputs so as to control it.

Yet they then say the inputs are *not* put through.

Which is it? I was under the impression that the EQ would be effective on the AUX and Radio outputs due to what I states above, but this is not the case?

The visuals are modular and have a couple of major entry points: one is "analyse", called with a 4608 byte buffer of sound data, which does the necessary FFTs or whatever is needed for that visual. The second entrypoint is "draw", which actually draws the visual. Some visuals simply don't use the "analyse" (or will survive fine without it) - like the 3d dot-shapes.

The output stage is in the DSP, which can select digital in (from the SA1100), radio or aux input. The DSP applies all the sound processing (bass, treble, fader, balance, EQ) and then puts it out of 4 independent DACs it has onboard.

We will be releasing info about how to do your own visuals, but we are going to change the call interface to them - at the moment, they're not very friendly to write as they are just a binary block which you call the first word of with opcodes (as they were written in the RiscPC's built-in assembler by Toby :) ).

Hugo

This is correct. The aux is digitised *by the dsp* (as is the radio's MPX signal) and processed internally. The DSP does not feed the radio/aux input into the strongarm, which is where the visuals happen.

Hugo

I assume then, that input source selection is made by the ARM by controlling the input souce to the DSP, either by a DSP input selection, or by controlling input selection to a single multiple-input pre-amp (which has pre-set input gains for each input, such as the radio - again under ARM control?)?

If this is the case, then when the user selects input source on the menu, the ARM must actively set the input channel for the DSP, and then de-activate the visuals, presumably since the MP3 player is paused when the input source changes.

Can the visuals not be left active (even though they no longer have an activity stimulus from the MP3 player) when the select takes place, even if the MP3 player is no longer active as input source to the DSP?

It is technically possible for us to support audio-independent visuals in tuner or aux mode, however there are issues in the code that need to be address before this can happen. It's on the list, but it's not a priority.

Rob