User

03.05.2007 06:16:28

I've noticed something about the way RB sends keypresses. Let's say I set the up and down buttons on my remote to the up and down keys, and set the play button to the return key, and set the menu button to run the following applescript:

tell finder 
set Var to (choose from list {1,2,3} with prompt "pick a number" 
return Var 
end tell

This should open a dialog with three choices (the numbers 1, 2 and 3) and cancel and OK buttons (with 'OK' highlighted).

When this dialog is open, I can navigate the choices with the up and down keys, and the return key will press the 'OK' button.

With a Keyspan DMR remote with buttons assigned to keys as described above, the up and down buttons will navigate the dialog and the play button will click 'OK' - just as should happen, with those buttons emulating those keystrokes.

But with RB, the remote is useless while the dialog is open. I have to choose with the keyboard or mouse. Then, after the dialog is closed, all button presses that happened on the remote control finally get sent to the system.

(Mira acts the same way as Remote Buddy.)

Any reason why the keyspan DMR software can successfully emulate keystrokes when an applescript dialog is open, but RB cannot? It's kind of annoying. 

User

03.05.2007 15:35:01

Hello Silas,

thanks for asking.

AppleScript is not threadsafe. Thus, it can't be executed 
asynchronously and Remote Buddy will only execute the next action 
once the previous one has finished.

This is also important as only this way the user is able to rely on 
an action to be finished before the next action is executed.

I.e. if you write a script to switch an application to a different 
mode and then use keystrokes to command in that mode - but keystroke 
that do something entirely different / unwanted, if not in the right 
mode - it could easily happen that the AppleScript needs longer to 
compile and execute than it needs to send the keystrokes, triggering 
different actions.

Keyspan's software uses a seperate process to execute AppleScript. 
This consumes additional memory and you can easily run into the kind 
of problems as mentioned above.

If you need a menu to select from, there's a much easier way to 
achieve this - especially without having to map several buttons to 
keycodes and such: Remote Buddy provides its own AppleScript command 
to open (hierarchical) menus that you can navigate with the remote. 
Please have a look at Remote Buddy's AppleScript dictionary in Script 
Editor.app for sample code. It's a clean design and really easy to use.

Best regards, 
Felix 

User

06.05.2007 00:42:05

Whoa.

I admit I am still exploring this software and so may be able to answer my own questions in time... but just so I'm clear: are you saying that RB can create Applescript lists (like the one described above) in the RB menu, and navigate them there? That would be absolutely amazing - it would be far and away the most useful and customizable media browsing solution out there.

(For background purposes, I have a media center run entirely on Applecript... it's not as pretty as RB or FrontRow, but it's much more flexible. I've been looking at replacing it with a prettier piece of software, like FrontRow or RB or Mira, but none has been perfect. If the above paragraph is accurate then RB becomes the clear winner. I have to look into it.) 

User

06.05.2007 02:23:17

Okay, I've looked into this some more, and it is indeed very well-done. And I have a couple more questions (of course):

1) So I can navigate Applescript lists using RB's UI by running a script from outside RB and using the command

tell application "Remote Buddy" 
showmenu ..... 
end tell

But, when navigating that menu, going up and down is not as smooth, and does not accerelate, as when navigating the real RB menu. Any idea why? It would be great if this were improved.

2) Due to the above limitation, it would be preferable to call such a script as an action in the actual RB menu. But then I run into hierarchy problems. For instance: by running a script from outside RB, I can do the following (note, this is not real Applescript code, it just simulates what the code would do):

tell application iTunes 
...set _TVshows to show of (tracks of library whose genre is tv shows) 
end tell

tell application Remote Buddy 
...showmenu with items _TVshows with return value 
...set show_name to result 
end tell

tell application iTunes 
...set _episodes to name of (tracks of library whose show is show_name) 
end tell

tell application Remote Buddy 
...showmenu with items _episodes with return value 
...set episode_name to result 
end tell

tell application iTunes 
...play episode_name 
end tell

That would generate successive menus, each of which would depend on the result of the prior one. If I understand the showmenu Applescript command for RB, this cannot be done from within RB, because all sub-menus must be contained within the brackets of the showmenu variable.

Is that correct? Is is not possible to create sub-menus based on a variable returned as the result of a higher menu? Or is my understanding of Applescript and RB unsophisticated enough (I admit I am an amateur) that I just cannot see it?

Last edited: 06.05.2007 02:26:25 

User

07.05.2007 14:13:01

Hello Silas,

thanks for asking.

Regarding your questions:

1) Your observation is right. The Remote Buddy menu and menus created 
by AppleScript use different handlers to drive the menu (it's in fact 
more complex than that, but in essence, this is right). I have 
forgotten to add accelleration support to the AppleScript handler. 
I'll add that.

2) Good question. As menu handling is different from within actions 
(=> you call the menu command - and your handler is called upon 
return) than from outside of Remote Buddy, I'm not sure whether this 
"recursion" inside actions will work.

If it does not, you can still work around it by storing the selection 
value you want to use in temporary storage using the respective 
AppleScript commands of Remote Buddy, then - from inside the handler 
- make Remote Buddy execute your action using its action unique 
identifier (both things - triggering execution and retrieving the 
action unique identifiers - can be done via AppleScript).

However, this is probably overly complex. And it would still not give 
you accelleration support, as the handler driving the menu is still 
the same.

Btw, you could completely replace Remote Buddy's menu with your own 
AppleScript by

1) Creating an action triggering your AppleScript and checking its 
"global" checkbox in Behaviour Construction Kit.

2) Replace the "Open Remote Buddy menu" action with the action (found 
in category "Miscellaneous" in the popup)

Best regards, 
Felix 

User

07.05.2007 19:15:43

 
 
Silas, I'm *very* curious as to your setup. Why use Applescript to drive everything? More importantly, what's the user interface to such a setup?

I too have a media center using an Intel Mini Core Duo and an RF wireless keyboard with integrated mouse, and the other usual suspects (HDTV and stereo amp).

But with both RB and Controller Mate (for the keyboard), I have a very powerful set of interface tools to control nearly everything (still working on some kind of Mac-centric universal remote control).

So I'm keenly interested in your setup! Any links to share? 

User

08.05.2007 15:05:55

As I thought, it looks like part of this problem is just that I'm not good enough at Applescript. I guess what you're saying is that I could use the showmenu command like this:

showmenu {1, "A", {2, "X"}, 3, "B", {4, "Y"}}

Where A and B are actual values and X and Y are variables, defined elsewhere in the script. Actually that doesn't seem so difficult; the hard part seems to be when the top-level values (A, B, C) are themselves defined dynamically by an Applescript... it seems hard to match them with the next-level values (X, Y, Z) when at the outset you don't even know what neds matching. If that makes sense.

I started to playing around with making my own menus triggered by outside Applescripts to replace the RB menus, and can kind of get it working (acceleration would be amazing btw). But I ran into another slight problem/fodder for a suggestion: I noticed that when RB performs an action (any action, not just these Applescript actions) it stays in the foreground, and the user has to dismiss the menu. In this case it causes problems because the Applescript menu and the RB menu appeared at the same time.

Actually I now see that it would be trivially easy to get around this by calling the Applescript-derived menu from a butotn press, rather than from the RB menu. But consider other events: I browse to a track in iTunes and start playing it, or tell EyeTV to change the channel. When most users do such things with normal remotes, they then want to get down to the business of watching that new channel, or listening to that song. Maybe there should be an option to dismiss the RB menu automatically whenever an action is triggered?

Sorry to be nitpicky, I'm just having fun discovering the ins and outs of this very flexible application. 

User

08.05.2007 18:20:28

iRob, my setup is kind of a long story, because it's been a long process tweaking it. It derives from two principles: Keep It Simple Stupid, and the need to control things remotely.

When I first put a mini (going for the cheapest possible solution here, so I use a pre-owned G4) under the TV, FrontRow & MediaCentral et al. either did not exist or weren't really usable. There was Windows Media Center and MythTV, but I questioned the premise of those applications' UI (and now FrontRow's UI). People consume different media in different ways, so why have a single UI to do it? Most importantly, I decided that 1) you should not need a screen to control music, since music is not a visual medium; and 2) people listen to music more often than any other media, and do so in the background while engaging in other activities, like reading or cooking or whatever, so the 'idle state' of a media center should be an active (if paused) music player. Contrast that with FrontRow et al., where the 'idle state' is a top-level menu, and you need to burrow down to play music. In my setup, I can walk in the door and press one button and music (from whatever playlist is up) will play on my stereo... just like with a CD player, you can walk in the room, press one button, and the CD that's in there will immediately play. No fussy menus.

So I did away menus altogether: I attached semi-complex applescripts to my Keyspan DMR buttons, like:

tell itunes pause 
tell eyetv activate 
delay 3 
tell eyetv fullscreen

Or, when a DVD is finished playing:

tell DVD player quit 
tell finder eject DVD 
tell itunes activate

I could get to any application I wanted (but kept it to a few apps, for simplicity's sake) from the remote control, with no menus. Four extra buttons on the remote were set to cycle through five playlists each, organized thematically, so I could get to any of 20 music playlists with a few button presses.

For more fine-grained control, I set up a small program on my desktop computer that could control the music remotely, slowly developing applescripts that would choose playlists, artists and albums, toggle shuffle, and even replicate a jukebox function. (A semi-finished version, called 'nTunes,' can be found on scriptbuilders.net if you're interested.)

Finally, I started to watch movies and TV shows through iTunes and wanted access to them (as well as the more fine-grained access to music) from the remote control. So I bit the bullet and set up a menu system from the remote control, basically just adapting the scripts from the nTunes remote application. The menu script is pretty complicated and took a long time to perfect, but what it does is pretty simple:

choose from list {playlist, artist, album, movies, archived TV shows, live TV} 
if result is "playlist" then choose from list {all playlists from iTunes} and play result 
if result is artist then ... 
... 
if result is "movies" then choose from list {itunes tracks whose genre is movies} 
... 
if result is "live TV" then tell application eyetv to activate and go to fullscreen

I set my display to sleep after a minute, for saving power when listening to music (set the remote control buttons to short applescripts rather than keystrokes to avoid triggering the screen), and conveniently, the display knows not to go to sleep when there is fullscreen video playing.

Only two problems with my setup: it uses the ugly Applescript dialogs for menus (they can be hard to read when I jack my resolution up to 720p) and I'm stuck with the Keyspan DMR for its Applescript and Keystroke triggering. If I can learn to adapt Remote Buddy to mimic my setup, 1) I will have a better-looking menu system, that still stays out of the way when I want it to; and 2) I can ditch the crappy Keyspan DMR and use a better remote like the Keyspan Frontrow RF or the Wiimote. 

User

08.05.2007 19:38:20

Excellent write-up, thanks Silas! I love bouncing ideas around with fellow Mini owners. With the Intel Mini, I've got the Apple Remote with built in IR receiver. I like not needing extra hardware to get remote control functionality.

 
So I take it you are using a Mac display on your Mini? I ask because my latest infatuation is coming up with a good way of controlling external equipment through my Mini. The only way I know of that could be done now with off-the-shelf equipment would be with a USB IR blaster, like the IRTrans or ZephIR. I'm just not sure about the difficulty using their software. With Remote Buddy, I'm very close to ditching my Harmony Remote!

 
I agree with this. See my comments below regarding the utility Synergy. I believe it uses Applescript to talk to iTunes in the background. Plus, it gives you nice feautures like shuffle, track advance control, rating. However, it uses keyboard shortcuts to activate.

 
Having a dedicated menu window for iTunes has its advantages (for me). I love getting good use out of my display while listening to iTunes. If I'm not sure what song is playing or who sings it, I walk over to the media center and take a look. Front Row displays the album art quite large, and all the track info is equally large. Very readable.

Also, keep in mind that if you quick exit from Front Row while playing music, the music is uninterrupted, since Front Row is really just a pretty skin interface to iTunes (among others).

But I see your point. You do indeed have to "burrow down" to get to the music from Front Row. And as far as displaying track info conveniently, there are other tools for this. Even Remote Buddy has a "floaty" option for this in the iTunes Behavior. At the moment, it's not very customizable. Personally, I've been a long time user of Synergy. It's another floaty utility that pops up with iTunes tracks change. Very nice for this kind of functionality too, especially when you're not in Front Row.

 
This is precisely what I *love* about Remote Buddy. It's just so darn good looking and the size is customizable for high resolution displays. 

User

09.05.2007 05:56:41

 
Actually no, I use a Dell (gasp!) W3000 30" LCD TV. It goes into power saving mode when there is no input, i.e. when the Mini's display goes to sleep. As soon as there's any input, the TV comes back on again in couple seconds, about the same as if you actually powered it on. When I'm controlling iTunes with the remote it uses Applescripts, which don't trigger this; but navigating the Applescript menus uses emulated keystrokes, which do (I have Finder call up the menus, so the buttons have different functions compared to when iTunes is active.)

For a while I used the irTrans + iRed to turn the TV on and off, until I discovered this more efficient method. The irTrans was not great because the little wired blasters attached to it were inconsistent. But I am about to bring it out of retirement, to use with the new EyeTV and a digital cable box (can't wait to have cable again!) To get around that problem I'll just position the actual irTrans unit in front of the cable box, and not rely on the wired blasters. I should say that I've heard the ZephIR software isn't (wasn't, anyway) great... but the iRed software is extremely good, and importantly, it has great Applescript support. It was very easy to integrate into my setup.

I should also say that my goals are a bit different from yours, and from most people who do this stuff. I want my Mac media center to be as cheap as humanly possible, and also as simple as possible. So I use a pre-owned G4 Mini; and I bought a refurbished Dell TV dirt cheap. A great thing: it's not technically an HDTV, but it is capable of displaying (not receiving) a resolution of ~1360x768. So As a display for the Mini it can actually show me 720p content (as long as the little G4 can handle it). Likewise, there aren't many other components to control... I use a $100 set of JBL creature II speakers so I'm limited to 2.1 sound at about 50 total watts. I have a small apartment, so it's good enough.

The other problem I have with FrontRow is that much of my music control is done with my little remote application on the iMac. That app remotely controls iTunes, not FrontRow (which is not scriptable). So there could be conflicts if I play an album through FrontRow, then tell iTunes to play something else from the iMac; if I go back to using the remote, FrontRow won't know what's going on.

 
I did notice the Remote Buddy 'floaty display' thing, it's very nice. I see that you can tell RB how long you want it to display... it would be great if you could assign it to a button to call it up at will, and then let the display go back to sleep after you've seen it.

I'll have to check out Synergy as well, I've never heard of it. 

User

09.05.2007 06:15:39

Oh yeah, in regards to the perfect remote control:

My mom just got a Harmony. (Needs me to help set it up, of course, and also to integrate with the Mini I'm giving her - just FrontRow for her, we're keeping it simple.) The Harmony remote is pretty great. As I mentioned in another thread, if you could get it to emulate a Keyspan iTunes remote with 17 buttons, and used Remote Buddy to assign those 17 buttons however you want, it would be a powerful setup.

But the design of the Harmony is very busy... there's a LOT of buttons on that thing. I prefer simplicity. The Keyspan DMR/iTunes/Express remotes have 17 buttons, which is pretty good. Unfortunately their industrial design is horrendous, you're liable to get carpal tunnel using the things.

Six buttons is too few I think; 12 or so would ideal, maybe even less since with Remote Buddy you can offload less-used actions from buttons to menu items. So my vote is for the Keyspan FrontRow RF (same crappy Keyspan design, but better button placement and spacing than the others) which has 9 buttons and has great directionless RF range, or else for the Wiimote, which I think has 10 buttons and an amazing form factor, for which you trade range and battery life. With Remote Buddy, irTrans and some inventive Applescripts, you really could have complete control over all your media components with a very small, simple remote control. 

User

09.05.2007 18:56:01

AppleScript has it's own pitfalls when combing arrays. I.e. with

set sampleArray1 to { 1, 2, 3 } 
set sampleArray2 to { 4, 5, 6 }

set combinedArray to sampleArray1 & sampleArray2 
set encapsulatedArray to sampleArray1 & { sampleArray2 }

will give you

{ 1, 2, 3, 4, 5, 6 } for combinedArray

and

{ 1, 2, 3, { 4, 5, 6 } } for encapsulatedArray

That info itself may be helpful when creating hierarchical menus fit 
for "showmenu".

Regarding the execution of actions and the dismissal of Remote 
Buddy's main menu (the showmenu menu should always be dismissed upon 
a selection): 
absolutely true - unless an action exports a special flag that the 
menu should be closed. So the functionality is there - it's just 
currently not settable in the BCK. It will be, though.

Best regards, 
Felix 

User

09.05.2007 19:20:02

[..]

 
Noted down ;-)

Best regards, 
Felix 

User

10.05.2007 07:14:23

Whoa, arrays. See, now we're getting beyond my Applescript expertise. I see that it might be possible to piece together a large, complex array from various bits of dynamically-created information, and in the end you'd have a single multilayered menu. It would be very complex though, and to try it would be a major undertaking... maybe one of these weekends.

What I was trying to do instead, is have successive menus, passing the result of one to the next. I actually got this working externally, but can't seem to attach it to a button as a RB action. Here's an example:

Global menu_choice, playlist_list, playlist_choice 
tell application "remote buddy" 
. showmenu with items {1, "choose a playlist", 2, "void", 3, "void #2"} menu name "Main Menu" with return value 
. set menu_choice to result 
end tell 
if menu_choice is 1 then 
. tell application "itunes" 
. . set _playlists to (get name of user playlists) 
. . set playlist_list to {} 
. . repeat with _playlist in _playlists 
. . . if playlist does not contain _playlist then 
. . . . set playlist_list to playlist_list & _playlist & _playlist 
. . . end if 
. . end repeat 
. end tell 
. tell application "remote buddy" 
. . showmenu with items playlist_list menu name "pick a playlist" with return value 
. . set playlist_choice to result 
. end tell 
. tell application "itunes" 
. . activate 
. . set playlist_choice to (playlist_choice as string) 
. . set view of browser window 1 to playlist playlist_choice 
. . play playlist playlist_choice 
. end tell 
else if menu_choice is 2 then 
. return 
else if menu_choice is 3 then 
. return 
end if

Paste that into a Script Editor window and press 'run' and it will successfully take you through two successive RB-style menus, and culminate with iTunes playing the playlist you choose.

But paste that into the Applescript box of a custom action assigned to a button in Remote Buddy, and it doesn't work. It compiles successfully, but after the first menu disappears the script stalls and no other menus appear. I don't know if it hangs while trying to process the iTunes command to get all user playlists,or while trying to move the global variables between the command for the different applications... but it hangs on something.

I tried saving the script as a run-only application and having RB open it (with an Applescript such as 'tell application "Finder" to open application "menu script"') and the whole system gets bogged down.

So, can we not do successive 'showmenu' commands in Applescripts executed by RB? Is the only recourse to generate a single, massive 'showmenu' array and call it once?

Edit: 
[If you're curious why I added each playlist twice to playlist_list, it's because of the way RB handles showmenu arrays. Each menu item has a first value (here 1, 2 and 3) that is used by RB to process the menu choice, and a second value (here "choose a playlist", "void" and "void #2") that is actually displayed in the menu. By adding two instances of each playlist these two values become identical, and it becomes easy to pass the values along to successive menus.]

Last edited: 10.05.2007 07:20:07 

User

11.05.2007 06:38:31

Okay, I've figured out how to use variables in arrays. I may be able to pull this stuff together into a big menu script, given a few hours to piece it together... and if so it will definitely be superior to the successive-menu approach above.

But out of curiosity, why does "with return value" not work from inside Remote Buddy? (That seems to be what's holding up the successive menus implementation.) 

User

11.05.2007 19:57:01

Hello Silas,

the problem is that you may not use "with return value" from within a 
Remote Buddy action, as what will happen is this:

1) Actor executes AppleScript inside Remote Budy (fine) 
2) AppleScript calls a Remote Buddy command (fine) 
3) Now where it breaks: Remote Buddy executes the command. During 
execution, it checks whether the "return value" is true. If it is, 
Remote Buddy will tell Cocoa to suspend the execution of the script 
and that it will send the return value later. It's just that the 
script that is sent to sleep is executed by Remote Buddy itself. In 
the main thread (thanks to AppleScript not being thread-safe - not 
even to the point as that it could safely be executed on a seperate 
thread). AppleScript locks up.

The solution is to return immediately and call into the same 
AppleScript again lateron, but this time in a handler. That's what

on menureturn(hiddenID, menuname) 
... 
end menureturn

is for. That's also why two examples are provided in the AppleScript 
dictionary - once for usage inside - and then from outside of Remote 
Buddy. If you use the handler-method, you can execute your entire 
script inside an actor just fine. Using the menuname as identifier 
will further easify the handling of the result value.

The last open question was whether you can - from within that handler 
- call showmenu again and whether Remote Buddy would still know which 
AppleScript actor it should return into. I did not think of this 
during the design phase. So I just did a quick code audit - and it 
looks good. It should work just fine.

Hope that helps ;-)

Best regards, 
Felix 

User

12.05.2007 02:49:15

I tried this, but RB does not seem to tolerate more than one instance of a menureturn handler in a single script, either nested inside each other or successively. I think the idea of successive menus with the result of one passed on to the next might not be possible.

Here\'s another question: if in my profile, I set the iTunes behavior to be one option, the music browser is part of that behavior. Can the iTunes music browser be separated from the iTunes behavior and be given its own place in a menu? Can it be assigned to a button? Can it be replicated in the BCK, so as to make a globally available version of it for those purposes?

Last edited: 12.05.2007 22:55:22 

User

13.05.2007 07:19:10

In case anyone's interested in this topic, I'll say that I hit upon a solution. Remote Buddy does not like to see multiple menureturn handlers in a single script, so the way to do this is to have different bits of script generate the dynamic content (in this case, all artists, albums and playlists from iTunes) and then combine them all into one huge arra - keeping in mind Felix's advice above on creating/combining arrays, to make sure that everything is properly nested within brackets.

The problem with that is that to create nested groups of dynamically-generated data, the script has to run doxens of repeat loops within dozens of repeat loops. My iTunes library has hundreds of artists and albums, so all those repeat loops mean a menu won't show up for 30 seconds or so. Not ideal.

The solution is to set up a separate script to generate the huge array and write it to a text file (not unlike the way iTunes itself uses an XML file for itw own data). Attach it to a daily iCal alarm to update every night. Then in the Remote Buddy script, simply write a few lines telling Finder to read the data in the text file as a list, and run a showmenu command with the resulting (global) variable as the items. The menu pops up instantaneously and functions normally. 

User

14.05.2007 15:54:10

There shouldn't be a problem to use if commands inside the "on 
menureturn" / "end menureturn". You should be able to use pretty much 
anything available in AppleScript in there. Including such basic 
things as if clauses, of course.

Your sample code lacks the end menureturn part btw. Maybe that's the 
source of your problem.

Best regards, 
Felix 

User

14.05.2007 16:45:09

Phew, you're going to great lengths there ;-)

But basically this (pseudocode) should work:

... 
showmenu .... 
...

on menureturn(hiddenID, menuname)

if menuname is "mainmenu" then 
if hiddenID is music then 
showmenu .... menu name "music" 
end if 
end if

if menuname is "music" then 
if hiddenID is artists then 
showmenu .... menu name "music.artists" 
end if 
end if

if menuname is "music.artists" then 
.. 
end if

end menureturn

Multiple on menureturn/end menureturn blocks of course will cause 
problems. But using "menuname" as a way to distinguish between 
several different menus should work just fine. Please let me know, if 
you find any issues with that methodology, so I can have a look at 
and eventually fix any existing problems.

Regarding the 30 seconds to build lists of albums, tracks, etc: 
welcome to the lightspeed AppleScript support in iTunes ;-) .. Remote 
Buddy avoids AppleScript for iTunes browsing whenever possible for 
this very reason.

Best regards, 
Felix 

User

15.05.2007 00:06:23

 
 
Indeed... but I get a lot of satisfaction from figuring out how to make these things work. The text-file database idea struck me like a bolt of lightning, and works extremely well - I can generate the whole menu array from the script that writes the text file; and the entirety of the Remote Buddy action deals with the results.

And, I did get the if/then blocks working within the menureturn handlers, for the most part...

 
Wow - a third way! I didn't even think of that. Quite elegant, and cuts down on lag by only generating one portion of the menu at a time. Of course, you lose the ability to travel up and down the menu hierarchy, as you can can with a single menua array (though you could certainly replicate it with a menu item that sends back to the prior menu).

 
I'll let you know of any issues I discover in my experimentation.