[QLab] client-server Qlab

[Alex Neumann]

Hey all,
I had an idea today, and as far as I can tell, the last time it was
discussed on the list was back in the 1.0 days (I think Jeremy Lee
brought it up sometime in 2007).
Has there been any more thought about creating a client-server
functionality in Qlab allowing multiple users to edit/run a cue-list
at the same time (different than using ARD or VNC...)?

I'm thinking specifically of the way that Filemaker allows multiple
users to connect to and edit a database.

I feel like being able to separate the play head from the selected cue
was a step in the right direction in terms of this, but it would be
nice for a designer to be able to connect to the playback machine and
edit cues without changing the screen of the operator (eg -
programming ahead, or tweaking levels after a cue has gone, that sort
of thing). Additionally, from an assistant's point of view it would
be nice to be able to review/track changes that the designer makes
after the fact without affecting the screens of either the designer or
the operator.

Is this possible, perhaps as a 3.0 addition?
________________________
Alex Neumann
neuman...@gmail.com
cell: 617.501.1480

www.soundsneu.com

________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab

[Charles Coes]

I don't mean to be negative. For high level users it would be fantastic.  The extra 4 steps in signing on every day would be nothing, and the networking knowledge likely necessary to make it work would be no hurdle.  For the high school students using the free version to playback four effects it would probably be too much.  At this point either the less ambitious users are left behind or two versions of Qlab exist.  Neither seems to fit with the desire

If the operator is concerned about watching his screen change, it wouldn't be too hard to build a remote screen for him/her that showed the currently running sequences and the cue on deck.  Those handles exist for scripting and it would just take some programming time to spit them out to a lemur or some sort of software face plate.  I know this puts an onus on the advanced userbase, but heck, it's what makes us advanced isn't it?

Charles Coes
cco...@gmail.com 
www.charlescoes.com
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." - Buckminster Fuller

[Andy Dolph]

I disagree - much like the way FilemakerPro works - if you are only
using it on one machine you don't even have to know that the
networking capabilities exist. But if you want to turn them on, they
are there under the hood.

I like the idea of a client server model for a different reason - it
makes it easier to run "headless" machines for video.

It's also great for being able to quickly take a laptop out in the
house and tweek levels without having to deal with the audio
connections (I know that can be done with VNC, but it's slow)

Andy

On Sun, Apr 25, 2010 at 9:44 PM, Charles Coes <ccoes...@gmail.com> wrote:
>  For the high school students using the free version to playback four
> effects it would probably be too much.  At this point either the less
> ambitious users are left behind or two versions of Qlab exist.  Neither
> seems to fit with the desire

________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

--

Change your preferences or unsubscribe here:

http://groups.google.com/group/qlab

[Andy Leviss]

Y'all know that lister Jason Tratta has an alpha out of a version of
Merqury that provides blind editing for QLab, right?

http://jasontratta.com/

Again, it's an *alpha*, so buyer beware, some functions not functional
yet, etc, etc, but it is coming, and you can play with it if you're
not scared of alphas :-)

--A

[Søren Knud]

Take a look at the guy sitting next to you.. And his grandMA – Then you will se great networking. (if he has more than one MA :-)

Den 26/04/2010 kl. 02.46 skrev Alex Neumann:

> I'm thinking specifically of the way that Filemaker allows multiple users to connect to and edit a database.

[Taylor John]

On 26/04/2010, at 7:33 PM, Søren Knud wrote:

> Take a look at the guy sitting next to you.. And his grandMA – Then
> you will se great networking. (if he has more than one MA :-)
>

I couldn't agree more. When will QLab have this level of networking.
I find it so annoying to have to update the smallest change on my
multiple machines manually.

Master/ Slave mode or Standalone. Well there is another topic all
together.

cheers

John T

[Paul Gotch]

On Mon, Apr 26, 2010 at 10:22:29PM +1000, Taylor John wrote:
> I couldn't agree more. When will QLab have this level of networking. I
> find it so annoying to have to update the smallest change on my multiple
> machines manually.

You could build it using xgrid, so you have a slave machine to actually
render video etc. but you only have to have one cue list. There is the
problem that you need to sync out media files to the remove machines
etc. This could be made automatic when the file changes on the master
though.

You also have to have logic to know which outputs are on which machines
and detect things that you can't do because they aren't all going
through the same videocard or mixer device.

It would be very powerful for those of us that need it and understand
the limitations. It might generate lots of support calls from less
sophisticated users though.

I think this is very much a 3.0 or even the next version after that
feature as getting it right would require a lot of design work. I
imagine it would be quite expensive as well due to the relatively small
number of QLab users who would use such a thing vs the engineering time
to implement and support it.

-p
--
Paul Gotch
--------------------------------------------------------------------

[Taylor John]

On 26/04/2010, at 10:44 PM, Paul Gotch wrote:

It would be very powerful for those of us that need it and understand
the limitations. It might generate lots of support calls from less
sophisticated users though.

I think this is very much a 3.0 or even the next version after that
feature as getting it right would require a lot of design work. I
imagine it would be quite expensive as well due to the relatively small
number of QLab users who would use such a thing vs the engineering time
to implement and support it.

What then a very simple addition to the bundle workspace feature which could be "Bundle recent changes to backup machine" ??? We have enormous shows with over 10 GB of data and to bundle small changes takes forever and is such a waste. A smaller solution would be welcome.

regards

John T

[Paul Gotch]

On Mon, Apr 26, 2010 at 10:52:43PM +1000, Taylor John wrote:
> What then a very simple addition to the bundle workspace feature which
> could be "Bundle recent changes to backup machine" ??? We have enormous
> shows with over 10 GB of data and to bundle small changes takes forever
> and is such a waste. A smaller solution would be welcome.

It's only a temporary solution but OS X comes with a commandline
utility called 'rsync' which can sync directories between machines. I
suspect one of the AppleScript experts on the list could knock
something which wraps rsync to do what you want.

[Rich Walsh]

On Monday, April 26, 2010, at 02:09PM, "Paul Gotch" <paulg...@chiark.greenend.org.uk> wrote:
>It's only a temporary solution but OS X comes with a commandline
>utility called 'rsync' which can sync directories between machines. I
>suspect one of the AppleScript experts on the list could knock
>something which wraps rsync to do what you want.

We use this tool to synchronise between machines (recreating it from scratch doesn't seem worth the effort!):

http://synkron.sourceforge.net/

You could also look at ChronoSync. We did a thread about this last year:

http://groups.google.com/group/qlab/browse_thread/thread/dc1b4fd94884bc1e/612078e276a68c38?lnk=gst&q=syncing#

Rich

[Charlie Richmond]

On Mon, 26 Apr 2010, S�ren Knud wrote:

> Take a look at the guy sitting next to you.. And his grandMA � Then you will se great networking. (if he has more than one MA :-)

And of course, SoundMan-Server, but the SM-S cue is being removed from QLab.

C-)

[Matt Otto]

When this discussion originally came up way back when I was against the idea. If my memory serves a lot of the client server idea was discussed by way of LCS where there is dedicated hardware that multiple computers can connect to. 

However Alex has hit on a really great point. The sharing of a database in FileMaker is really quite fantastic. You really can have no idea its there and ignore it and  FileMaker will remain just as it is today and feel completely like a single client program but if you do need the functionality its simple to turn on (one click of a radial button) and it just works. Other FileMaker clients can see it being shared and connect to it effortlessly. I imagine its all built upon Rendezvous (formerly Bonjour) but I think FileMaker has had this option longer than that technology was built into OS X. Another great feature of FileMaker’s sharing ability is that it is not a program wide change but instead one based on the particular database you are using. 

I’ve also attached a screen shot of the FileMaker sharing option screen as a reference…

Matt Otto
(609) 707-2978
Off List: motto...@gmail.com
http://www.mattottosound.com

[Jake Davis]

>> lots of talk about xgrid, rsync, applescript, filemaker pro, etc....

it's almost like what is needed is some sort of Environment that
enables a Linkage between Multiple User Clients and Servers.  What
would be even better would be if this environment was open source and
setup to be adapted to any TCP based inter-application communication.
It would be even best if the environment  provides simultaneous
database updates to all clients via some sort of subscription scheme.
Experience with audio a plus.

... hang on a sec....

https://public.msli.com/lcs/muscle/

To quote the venerable Mr. Richmond:

"just saying"

I suspect that if Chris were interested, there is a way to implement a
muscled server into Qlab that would give everyone what they are asking
for, namely, the ability to have multiple, independent, control
surfaces that operate on the same database of cues and media.  I think
the analogy to the look and feel of FMP database sharing is a good
one.

But given the recent traffic regarding SM-S, I'm not so sure Chris is
interested in moving Qlab in that direction (though, admittedly, we
are talking about different things here.... Qlab as control surface
for external hardware v.s. Qlab as robust multi-client juggernaut)

If you couldn't tell, I'm all for a move in this direction.

Cheers,
-Jake-

[Jeremy Lee]

That's not really an issue here. Even with large shows (5-10Gb) it's terribly easy to just have a gigabit network hooked up. At the end of the day, just overwrite the entire set of files on the backup. Takes a minute or two, and everything is exactly the same on both machines.

Gigabit network is awesome and fast...

On Apr 26, 2010, at 2:52 PM, Taylor John wrote:

> What then a very simple addition to the bundle workspace feature which could be "Bundle recent changes to backup machine" ??? We have enormous shows with over 10 GB of data and to bundle small changes takes forever and is such a waste. A smaller solution would be welcome.
>
> regards
>
> John T

--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com

[Jeremy Lee]

You can *sort of* do this by deslecting "Playback position is always the selected cue" in the prefs. But when I've tried it, it seems to confuse more people than it potentially helps. A real client/ server solution would be fantastic.

On Apr 26, 2010, at 2:46 AM, Alex Neumann wrote:

> I had an idea today, and as far as I can tell, the last time it was discussed on the list was back in the 1.0 days (I think Jeremy Lee brought it up sometime in 2007).
> Has there been any more thought about creating a client-server functionality in Qlab allowing multiple users to edit/run a cue-list at the same time (different than using ARD or VNC...)?

--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com

[Taylor John]

On 29/04/2010, at 7:35 PM, Jeremy Lee wrote:

> That's not really an issue here. Even with large shows (5-10Gb)
> it's terribly easy to just have a gigabit network hooked up. At the
> end of the day, just overwrite the entire set of files on the
> backup. Takes a minute or two, and everything is exactly the same
> on both machines.
>
> Gigabit network is awesome and fast...

Yes this is exactly what we do but why wait till the end of the day.
Why run a rehearsal with bits missing on the backup machine or
adjustments made to the fade times or lighting timings. When ever I
change the master machine my backup is no longer in sync and no longer
a true Backup.

I would like to know how others run a second machine and keep the Qlab
workspaces (synced) during editing/ reharsals. Or is it not
possible????This is what I would like.

Any ideas???

regards

John T

[Paul Gotch]

On Thu, Apr 29, 2010 at 08:55:26PM +1000, Taylor John wrote:
>> Gigabit network is awesome and fast...
>
> Yes this is exactly what we do but why wait till the end of the day.

The limiting factor is usually the disk rather than the GE. On a good
day GE can do 80MBytes/s. Under ideal conditions with a serial transfer a
good piece of rotating rust *might* keep up with that. In the real
world it will be substantially slower.

Even at 80MByte/s a tens or hundreds of GB dataset still takes ages to
transfer.

-p
--
Paul Gotch
--------------------------------------------------------------------

[Christopher Ashworth]

Hi John,

Did you see the notes from folks about the various synchronization
tools that are out there? If all you need is basic synchronization of
files on two computers there are great solutions like ChronoSync or,
at the command line level, rsync. (I believe Rich Walsh mentioned
another one, although it escapes me at the moment.) These tools make
it possible to just transfer the data that changes between computers,
which makes the synchronization much faster.

Best,
Chris

On Apr 29, 2010, at 6:55 AM, Taylor John wrote:

> I would like to know how others run a second machine and keep the
> Qlab workspaces (synced) during editing/ reharsals. Or is it not
> possible????This is what I would like.
>
> Any ideas???

[Steven Devino]

On Apr 29, at Apr 29, 2010 6:55 AM, Taylor John wrote:

>
> On 29/04/2010, at 7:35 PM, Jeremy Lee wrote:
>
>> That's not really an issue here. Even with large shows (5-10Gb) it's terribly easy to just have a gigabit network hooked up. At the end of the day, just overwrite the entire set of files on the backup. Takes a minute or two, and everything is exactly the same on both machines.
>>
>> Gigabit network is awesome and fast...
>
> Yes this is exactly what we do but why wait till the end of the day. Why run a rehearsal with bits missing on the backup machine or adjustments made to the fade times or lighting timings. When ever I change the master machine my backup is no longer in sync and no longer a true Backup.
>

One suggestion might be a mirror drive for backup during rehearsal and a perhaps a redundant system for shows.

Of course I live in the land of community theatre where if the lighting board or the mixer dies the backup is we pull the piano out of the pit and go without mics. :-)


Steve

[Steven Devino]

On Apr 29, at Apr 29, 2010 7:20 AM, Paul Gotch wrote:

> On Thu, Apr 29, 2010 at 08:55:26PM +1000, Taylor John wrote:
>>> Gigabit network is awesome and fast...
>>
>> Yes this is exactly what we do but why wait till the end of the day.
>
> The limiting factor is usually the disk rather than the GE. On a good
> day GE can do 80MBytes/s. Under ideal conditions with a serial transfer a
> good piece of rotating rust *might* keep up with that. In the real
> world it will be substantially slower.
>
> Even at 80MByte/s a tens or hundreds of GB dataset still takes ages to
> transfer.

My math using your numbers says you can transfer a 1GB every 12.5 seconds.

Steve

[Taylor John]

On 29/04/2010, at 9:41 PM, Christopher Ashworth wrote:

> Hi John,
>
> Did you see the notes from folks about the various synchronization
> tools that are out there? If all you need is basic synchronization
> of files on two computers there are great solutions like ChronoSync
> or, at the command line level, rsync. (I believe Rich Walsh
> mentioned another one, although it escapes me at the moment.) These
> tools make it possible to just transfer the data that changes
> between computers, which makes the synchronization much faster.

These tools are a perfect solution and solves the asset copying. Is
there a future hope that the rsync command be included into Qlab to
keep it all tidy?? a background script that runs every time a file is
added? I know nothing about applescript, would this do it?

Also is there a way to update the workspace without closing and
reopening the back up machine??? Live updating i guess.

regards

John T

[Matt Otto]

But what if you need to run the cue right after you updated it? I don’t know about you but I’m not sure I’d feel that comfortable putting that much strain on a hard disk aand trust the resulting file transfer. Am I being too paranoid here? 

Matt Otto
(609) 707-2978
Off List: motto...@gmail.com
http://www.mattottosound.com

[Jeremy Lee]

On Apr 29, 2010, at 12:55 PM, Taylor John wrote:

> On 29/04/2010, at 7:35 PM, Jeremy Lee wrote:
>
>> That's not really an issue here. Even with large shows (5-10Gb) it's terribly easy to just have a gigabit network hooked up. At the end of the day, just overwrite the entire set of files on the backup. Takes a minute or two, and everything is exactly the same on both machines.
>>
>> Gigabit network is awesome and fast...
>
> Yes this is exactly what we do but why wait till the end of the day. Why run a rehearsal with bits missing on the backup machine or adjustments made to the fade times or lighting timings. When ever I change the master machine my backup is no longer in sync and no longer a true Backup.

I've never found the need for a live backup during rehearsals. I do often duplicate the show file and rename it (Tech 2 - lunch, etc) to keep incremental cuelist backups. If you're really worried about a computer crashing during tech and losing data, get a RAID drive set up with redundancy.

There are a LOT of things that I hope QLab is in the future. This just isn't one of them!

--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com

[Alex Neumann]

Since this topic has gone a bit astray from the original intention of
the post, I just wanted to chime back in and and say that I checked
out MerQury and though I really won't have a chance to play with it
until I get out of tech, my initial response is that it seems like a
GREAT utility and I can't wait to play with it more and see how it
develops. It seems to be almost exactly the sort of thing I was
talking about in my original post. Thanks Andy for making me aware of
it!

I have one question for Jason Tratta and/or anyone else who has played
with it extensively:
When I experiment with it I'm going to be limited to my two laptops,
so I won't be able to test this: Does it allow multiple users to
connect to the same Qlab server at the same time?

________________________
Alex Neumann
neuman...@gmail.com
cell: 617.501.1480

www.soundsneu.com

[Jason Tratta]

Yes!

You can in fact connect multiple clients to a MerQury server. If you are using the blind editor you could, theoretically, have as many people editing the workspace being served as you had computers. My development environment is usually 2 computers, on occasion I test it in our sound shops at STC on multiple macs.

To be clear, you can currently only edit levels, cue names, notes, pre and post wait times, and adjust wait and fade times.

If you are using the app for redundancy, there primary workspace (server) can push Go, Stop, Up & Down Selection to multiple clients as well.

A note to all, MerQury isn't finished...it's slowly getting there though. If you end up checking it out let me know what kind of errors you encounter. There are some bug floating around. I should have and update ready tonight with an updated blind editor.


Thanks!
Jason

On Apr 29, 2010, at 3:09 PM, Alex Neumann wrote:

> Since this topic has gone a bit astray from the original intention of the post, I just wanted to chime back in and and say that I checked out MerQury and though I really won't have a chance to play with it until I get out of tech, my initial response is that it seems like a GREAT utility and I can't wait to play with it more and see how it develops. It seems to be almost exactly the sort of thing I was talking about in my original post. Thanks Andy for making me aware of it!
>
> I have one question for Jason Tratta and/or anyone else who has played with it extensively:
> When I experiment with it I'm going to be limited to my two laptops, so I won't be able to test this: Does it allow multiple users to connect to the same Qlab server at the same time?
>