Stupid Ion Questions... uh, 7, I think

Ok, first principles.

I've got a (2) iPads that are runing the OSCrfr remote focus utility. It's really nice for focussing, the actual task it's intended for, but while it has GoToCue, and a Master Fader pair for Go/Back, *there's no way to see the cuelist*, which means that if you want to actually operate with it (it would be useful to be able to do this for, say, my church rental client, whose show is pretty simple), you have to *write the cue numbers for each sequence on paper* (or memorize them; I'm in my 50s; shut up), and that seems.. no fun.

The Ion's ability to build DS buttons for marked scenes automatically would be helpful, except that those buttons... don't do anything for me. They move the outline cursor in the cuelist (the thing with the three letter abbreviation with a P in it that I can't remember, ever). But they don't move the RED cue (current) nor the YELLOW cue (next).

I'm pretty sure double-clicking them in OSCrfr won't help, since there's an entire command-evaluation layer in between (it won't *get to the board* as a double-click), and there doesn't seem to be an Ion command which can follow up

[ Cue ] 105 {Enter}

on the command line to tell the board to *execute that cue*.

[Go] executes *whatever the next cue was in the cuelist*, not one you've just entered in that way, as far as I can tell.

And the alternative "build a macro for every scene manually" really grinds my gears; that's *not* why I use computers for this stuff, so that I can do a bunch of repetitive work manually all the time...


Does that clarify it enough? Are any of my observations/inferences incorrect here?

The cue list feature is standard with ETC's iRFR. Donate some money to charity and switch apps for playback.

With all due respect to ETC, does their RFR suck *a lot* less than it used to?

Jay Ashworth said:

With all due respect to ETC, does their RFR suck *a lot* less than it used to?

Click to expand...

Yes. It's better and in this case would do what you want.

I agree that some additional screens are needed in both the AlienStagcreaft app as well as the new ETC app, namely screens of the cue lists, tombstones, and magic sheets.

Or buy a Windows tablet and run Nomad as a client, with all custom magic sheets for those 'simple' that are never simple jobs.

Motion Computing 3500s are pretty cheap, and that idea hadn't occurred to me...

Nomad run as a secondary like that doesn't require a separate license, right?

A license dongle is required to run Nomad as a client. The good news is the bare minimum output license is all that is required. However, multi-console setups require a wired ethernet connection so a wireless Windows tablet won't work. On a somewhat happier note, the J3500 has an ethernet port.

As thought, maybe write the execution of cues, with times, into macros, then run the DS macro Page. You'd be able to write a description of the Macro/Cue that would be seen on the DS page of the newer iRFR app.

Sure, Steve, but I can run the Macro DSs from OSC, too.

Sk8? How would Nomad know what's underneath the TCP or UDP socket between the tablet and the console?

Latency.

I dunno; I'm not seeing unacceptable latency doing what I do from the OSCrfr, and that's wireless. I'll check ping times later in the week, but I'd be surprised if it was more than 10ms from the console through the router to the iPad. Probably be similar to a wireless PC tablet.

I thought you were suggesting that Nomad *would not talk to the network* over a wireless interface.

Another (read, the bigger) issue with wireless networking with Eos is that if the client and the master get out of sync or miss a packet the entire show will automatically do a full show resync/reload on all devices and it'll sit there until it finishes. Granted, this is true of wired connections as well, but wireless is far more susceptible to it due to the finicky nature of radio waves.

OSC is a much smaller package of information than keeping a client and master in sync in real-time.

Can it work? Maybe. But I wouldn't bet my name on it for a show.

Oh dear; that's an... unfortunate choice of architecture. :-}

And it's a couple orders of magnitude more complexity than is justified by the one additional feature I'm trying to add to my workflow for this issue, so that rules it out.

It's clearly time for me to call support, and ask them...

The answer, as it turns out, is that the command I'd forgotten about (since I almost never use it) is

LOAD

After you hit a Scene DS, you can LOAD, and *then* GO, and it should play that cue...

Which means I can RFE Alien for knob that enables that behavior to be automagic, since LOAD is accessible from OSC. #Nice

Alien doesn't have someone on here, do they?

@SteveB mentioned LOAD in his earlier post on this thread.

SteveB said:

Or “Cue 100 Load, Go

Click to expand...

So he did.

Alas, in the context I was in (in the middle of an OSC command autogenerated by OSCrfr from a DS autogenerated by Ion), it wouldn't help me, which is probably why I read right past it.

And I've gotten to test this (tap a Scene DS, hit Load and Go) and it works a treat both at the console and on oscRFR. I've pinged the ASC people about adding a configurable to make either the Load or both the Load and the Go automatic in the Scene DS panel, and he thought it was an interesting idea; they're looking into it.

Now that *I* think about it more, this seems an excellent solution to the "lots of my users can't handle an Ion" problem we talk about here pretty regularly, and not even necessarily with oscRFR -- maybe with just TouchOSC, preprogrammed, and running on a used $40 Amazon Fire.