Touch screensaver options ?

[michaelday]

The new colour screen of the Touch is really cool, with the ability to display album art, photos, etc.
... but .....
Will we also still have the option on the Touch to display the old traditional screen saver options of the SB3 ?
I've become attached to having the good old Analog VU meter, with the display needles that wiggle along with the music!

Cheers!
Mike

[JohnSwenson]

Yes there are analog VU meters, exactly what they will look like and how they behave is a matter of intense discussion right now, there are a lot of people that have the same feelings as you.

Another thing to remember is that the SB3 has had years of people developing plugins for it, at launch there will not be very many for the Touch, primarily because not very many people HAVE it! I'm SURE there will be a flurry of applet development soon after a large number of people get them in their hands.

John S.

[usch]

When the Radio and Touch were announced I (naively?) took it for granted that they would work with the existing software. Like, display the cover artwork as a background image and run two lines of text on top of it. I don't think this would be rocket science. I was quite disappointed when I found out that all 3rd party development has to be redone from scratch with the new players.

The color display is nice, but for me it hardly outweighs the loss of the music information screen, title switcher, saver switcher, and RSS news ticker.

[JohnSwenson]

The previous products could be customized by writing plugins to the server, the information on the display was sent over the network and put on the display.

In the new devices the screens are primarily controlled by the local processors but I think data can still be displayed from the server. This gives the option of writing third party applications the same as before (as a server plugin) or as an "applet" that runs on the local processor. Even if you retain a "plugin" and tried to use it directly without modification on the Touch it would be barely visible. The screen is much higher resolution with a very different aspect ratio, thus if you directly used existing plugins they would display as a little rectangle, probably not what you had in mind.

What Logitech chose to do was give developers the option to either modify existing plugins to display properly on the Touch screen or start from scratch writing a program that runs on the local processor. If a program is primarily working with the music files, searching, taging etc its probably best to run on the server as a plugin, if its primarily a graphical interface such as a visualizer its probably best as an applet where it can quickly draw to the screen.

A plugin that works with the database and just has a simple menu and or button interface should be easy to convert over. Something that has a complex graphical display may be a little tougher.

So I don't think its quite fair to say that all third party work has to be redone from scratch, some developers may choose to do so, some may quickly convert existing plugins.
It will be interesting to see what direction this takes.

John S.

[michaelday]

Thank you Gentlemen !
It sounds like when the Touch is released, it’ll at least be coming (right out-a the box) with a cool look’n Analog VU meter ~ screensaver option, which I’ll enjoy :-) ! ...
then in a short time, we should see many AMAZING plugins made for it – that take advantage of its new high-res display and onboard processor. Sure works for me.

This Touch is going to be a KILLER product ! Thanks !

Mike

[peterw]

The previous products could be customized by writing plugins to the server, the information on the display was sent over the network and put on the display.

Correct.

In the new devices the screens are primarily controlled by the local processors but I think data can still be displayed from the server.

Incorrect. For instance, see the response to my query about taking over the screen of a new player (as is very easy with the old gear): http://forums.slimdevices.com/showthread.php?t=42596 -- in short, it seems that there MUST be Lua code on the player; the server cannot "push" info as with the older players.

This gives the option of writing third party applications the same as before (as a server plugin) or as an "applet" that runs on the local processor.

Misleading. Plugins and applets have very different capabilities.

Even if you retain a "plugin" and tried to use it directly without modification on the Touch it would be barely visible. The screen is much higher resolution with a very different aspect ratio, thus if you directly used existing plugins they would display as a little rectangle, probably not what you had in mind.

What are you talking about??? The majority of "old" plugins don't do bitmapped graphics, they deal with textual displays. Typically a plugin specifies what should go on each of the two normal text lines on, say, a Boom. One line is guaranteed to be there; the other will be there in all but one of the common text sizes for Boom/Classic/etc. True, there are some plugins that use custom bitmap fonts (SuperDateTime for weather & sports icons, MusicInfoScr for the "alternative volume" display, the simple shuffle & repeat icons, etc). But the vast majority just specify text and let the Squeezebox handle layout.

What Logitech chose to do was give developers the option to either modify existing plugins to display properly on the Touch screen or start from scratch writing a program that runs on the local processor.

No, they chose to change the platform for the player, and to make more of the typical operations (like volume control) primarily "local". The fact that code can run on player or server is merely a byproduct of that fundamental decision. And, as noted above, each platform (SBS/server, SqueezePlay/player) has its own set of advantages and drawbacks. Often what was possible with 100% server-side Perl code for Boom now *requires* server-side Perl AND player-side Lua. And the current mechanisms for installing player-side code are terribly primitive -- especially that there's no way for SBS to "push" install to players, and player-side code is wiped out with any firmware update (which, as Controller owners know, happen more often than official SBS/MySqueezebox updates).

If a program is primarily working with the music files, searching, taging etc its probably best to run on the server as a plugin, if its primarily a graphical interface such as a visualizer its probably best as an applet where it can quickly draw to the screen.

True.

A plugin that works with the database and just has a simple menu and or button interface should be easy to convert over. Something that has a complex graphical display may be a little tougher.

Oh, yeah? How many have you converted, John? Do you have any tools you'd care to share for converting old-style INPUT.* code to xmlbrowse?

So I don't think its quite fair to say that all third party work has to be redone from scratch, some developers may choose to do so, some may quickly convert existing plugins.

On what are you basing your statements, John? I know you've been doing some serious work on the new platform, hacking Linux/ALSA configs, etc., but what experience do you really have writing plugins, writing applets, converting plugins to applets, and making plugins and applets interoperate?

I do think you mean well and generally do respect you, but I haven't seen anything to suggest you're very qualified to comment on these development issues, and your post contains some misinformation and apparent speculation.

[JohnSwenson]

Correct.

On what are you basing your statements, John? I know you've been doing some serious work on the new platform, hacking Linux/ALSA configs, etc., but what experience do you really have writing plugins, writing applets, converting plugins to applets, and making plugins and applets interoperate?

I do think you mean well and generally do respect you, but I haven't seen anything to suggest you're very qualified to comment on these development issues, and your post contains some misinformation and apparent speculation.

I've written several applets (for SBC and SBT) and converted one plugin to an applet. I was talking with a developer about one of these and was told that I could do it as a plugin instead of an applet. This included doing menus etc. Now I never actually got around to trying that so I really don't have experience with it. I was basing things on what I had been told.

I personally did not have too much trouble converting the plugin to an applet, but I'm already quite familiar with Lua having used it for other projects.

I apologize if I made things sound too easy, I was under the impression that a plugin could display on the touch.

I still don't think things are quite as bleak as having to completely start from scratch for everything. Having something working, even if it is on a different environment makes things much easier than starting from scratch.

I personally like Lua much better than perl, so I will most likely be spending my time (what little there is) writing applets. :-)

John S.

[peterw]

The color display is nice, but for me it hardly outweighs the loss of the music information screen, title switcher, saver switcher, and RSS news ticker.

You should follow Erland's work. I don't know about RSS, but he's been working hard on applet code that should address most of the expectations of current users of MIS, Title Switcher, and SaverSwitcher.

I was quite disappointed when I found out that all 3rd party development has to be redone from scratch with the new players.

Hopefully Logitech will at least relicense a bunch of the new player code (bug 14194) so that it's easier both for old-timers like me to port code, and for new customers to create brand-new software for the new platform. Please vote for that bug if you want to see more 3rd-party extensions for the new players!

BTW, it's not quite as bad as you suggest -- it's mostly things that either 1) have a user interface on the player or 2) try to intercept or change behavior that's no longer controlled by the server that need serious work. Some things were surprisingly easy to get working with Radio and Touch (like my SleepFade plugin), others only needed minor changes to work reasonably well (e.g., VolumeLock cannot prevent a volume change, but can quickly revert a change). But it's not simply "easy to convert over" as John wrote, either. :-/

[usch]

You should follow Erland's work.

I do. I've tried his Information Screensaver but could not get it to display anything on SqueezePlay, it only gave me a blank screen. I suppose it does work on the hardware players though.

relicense a bunch of the new player code (bug 14194)
Please vote for that bug if you want to see more 3rd-party extensions for the new players!

Yet another account to be created. *sigh*

[erland]

I do. I've tried his Information Screensaver but could not get it to display anything on SqueezePlay, it only gave me a blank screen. I suppose it does work on the hardware players though.

The Information Screen applet/plugin should work both on SqueezePlay and hardware players. However, it needs you to install both the Information Screen applet (in SqueezePlay through Applet Installer) and the Information Screen plugin (in Squeezebox Server through the Plugins tab).