Douglas.Arellanes@mdlf.org wrote:
> Akos and Ferenc,
>
> If we were able to change the definition of "on air" to mean either that
> "a playlist is in the scheduler" or "the station is in live mode", would
> that be an adequate description of "on air"?
>
> The scheduler returns information about its status currently, no? Does
> Live mode?

No, live mode does not.


Akos

------------------------------------------
Posted to Phorum via PhorumMail

Douglas.Arellanes@mdlf.org wrote:
> Does the scheduler know anything about Live mode being invoked, or is
> it only playing a silent playlist at that time?

there is no connection currently, per se, between the scheduler and a
client running in live mode. a live mode client does not connect to the
scheduler at all. there could be multiple live mode clients running at
the same time, on different machines.

as for Micz's definition:

> yes we did... on-air: the transmitter is broadcasting a signal. how
> does that translate to our system?
>
> either the live assist or the scheduler soundcard has an output other
> than zero

this is a wrong translation, as what gets broadcasted is actually
determined by an analogue mixer, which has as its possible inputs both
the audio from the scheduler, and that of other sources, like clients
possibly running in live mode. thus, even though the scheduler plays
something and also a live mode client is playing something, there might
be silence going out to the air. and vice versa - if none are playing,
there could be programming coming from a different source.

it's impossible to programatically determine what is actually being
broadcast. also, in a traditional studio, the 'on air' lamp is usually
an indicator handled manually (like any lamp on your desk, for example),
it just has the meaning - be silent, there's recording going on. I know
it looks cool & stuff, but it really is just an indicator.


But, if you really insints, we could make all live mode clients connect
to the scheduler, and flip a bit - 'hey, I'm a live mode client in
operation now!'. so, the scheduler would know if there are any live mode
clients in operation. this way you could have an indicator saying:
either there's something playing on the scheduler, or there's a live
mode client running somewhere. (see above, this wouldn't mean that
there's programming going on at all, though).


Akos

------------------------------------------
Posted to Phorum via PhorumMail

Micz Flor wrote:
> yes. which is why the on-air button just shows that some output is at
> one of the transmitter sound cards.

so if I'm at live mode, and I press 'stop', the on-air lamp goes off?
pressing 'play' again turnes it on?

------------------------------------------
Posted to Phorum via PhorumMail

At 15:25 14.03.2005, you wrote:
>Micz Flor wrote:
>>yes. which is why the on-air button just shows that some output is at one
>>of the transmitter sound cards.
>
>so if I'm at live mode, and I press 'stop', the on-air lamp goes off?
>pressing 'play' again turnes it on?


live-mode output
YES NO
scheduler mode
output
YES on-air on-air
NO on-air off-air


Micz Flor - micz@mi.cz

content and media development http://mi.cz
-----------------------------------------------------------------
http://www.campware.org -- http://crash.mi.cz -- http://suemi.de
"Good job. Hopefully he will go elsewhere..." (Sava Tatic)
-----------------------------------------------------------------

------------------------------------------
Posted to Phorum via PhorumMail

At 16:50 14.03.2005, you wrote:
>Can this on-air / off-air handling works with one master control room
>and two studios (clients)? to know who on-air?

for the time being it does not work anyway... the idea is more an
indication if there is something potentially on-air - but not to control
anything. not at this stage.


>On Mon, 2005-03-14 at 16:01, Micz Flor wrote:
> > At 15:25 14.03.2005, you wrote:
> > >Micz Flor wrote:
> > >>yes. which is why the on-air button just shows that some output is at
> one
> > >>of the transmitter sound cards.
> > >
> > >so if I'm at live mode, and I press 'stop', the on-air lamp goes off?
> > >pressing 'play' again turnes it on?
> >
> >
> > live-mode output
> > YES NO
> > scheduler mode
> > output
> > YES on-air on-air
> > NO on-air off-air
> >
> >
> > Micz Flor - micz@mi.cz
> >
> > content and media development http://mi.cz
> > -----------------------------------------------------------------
> > http://www.campware.org -- http://crash.mi.cz -- http://suemi.de
> > "Good job. Hopefully he will go elsewhere..." (Sava Tatic)
> > -----------------------------------------------------------------
> >
> >


Micz Flor - micz@mi.cz

content and media development http://mi.cz
-----------------------------------------------------------------
http://www.campware.org -- http://crash.mi.cz -- http://suemi.de
"Good job. Hopefully he will go elsewhere..." (Sava Tatic)
-----------------------------------------------------------------

------------------------------------------
Posted to Phorum via PhorumMail

Frans,

I guess I misunderstood the chain of emails about the pulldown menu. I
thought the consensus was to come up with a different design for the header
and pulldown menu that's why I sent over the old menu. Sorry about that.

Sangita

----- Original Message -----
From: "Frans van Berckel"
To:
Sent: Monday, March 14, 2005 2:31 PM
Subject: Re: [livesupport-dev] Re:pulldowns at least


> Dear Sangita,
>
> Is it a idea to create some index's to compare the one we have now?
>
> Thanks.
>
> Frans van Berckel
>
> On Mon, 2005-03-14 at 20:15, Sangita Shah wrote:
> > I agree completely with Micz that a universal style for the header and
> > pulldowns would make things look a lot more consistent. I'm willing to
try
> > out a few ideas and send them to you as soon as I can. I just wanted to
ask
> > if anyone liked the pulldown menu from the earlier HTML interface. You
can
> > see it at: http://a.parsons.edu/~sangita/livesupport/index.html. The
> > colors, hovers, etc. can be obviously be tweaked.
> >
> > Sangita
>
>

------------------------------------------
Posted to Phorum via PhorumMail

Hi, Sangita, Doug, micz,

I don't want to start over a new discussion about the layout. So if i
have to do almost all the steps at one's, i want to go for the navbar
apple is using at there website. http://www.apple.com

It's professional and because it's got two rows it's give us the
flexibility we want. It's got almost the same style we have chosen for
LiveSupport and it's simple to change (built-out) for the future
development.

Frans van Berckel


On Tue, 2005-03-15 at 11:22, Micz Flor wrote:
> (from the livesupport list)
>
> At 01:52 15.03.2005, you wrote:
> >I guess I misunderstood the chain of emails about the pulldown menu. I
> >thought the consensus was to come up with a different design for the header
> >and pulldown menu that's why I sent over the old menu. Sorry about that.
>
> hi sangita, doug, frans,
>
> you are all right, i should say...
>
> the idea is that in the long term:
>
> a) all campware software has some consistent look and feel in the HTML
> interface. the first step to achieve that would be to think of a consistent
> header and navigation for all software packages. in theory it would not
> matter what javascript / CSS / HTML pulldown solution we would settle with.
>
> b) the campware coding olymp is built from a small yet amazingly efficient
> and innovative group of people who are working on different products. since
> the projects come from different demands, times and financial brackets,
> they have developed to some extent independently from each other. they all
> do great work, but i thought we could improve the production cycles of new
> features and/or designs by standardising some of the interface elements. if
> we have one method to include new modules into the interface, that would
> make it easier to work on the libraries and classes under the hood - and
> throw them to the surface with the same method for all packages.
>
> c) the same goes for the CSS naming and logic. at the end of the day, forms
> and lists make up 80% of the interface operations. once we decide on a CSS
> / HTML logic for these elements, it could make the development much easier.
> you can even start a new application based on the existing CSS.
>
> at the end of the day that would mean...
>
> 0. to have this discussion at a later stage...
>
> 1. to possibly throw this into a days workshop for the upcoming campware
> summercamp?
>
> 2. decide on one method that could fit all packages (in HTML)
>
> 3. accept the fork under the time pressure for now, but let's try to run
> that extra lap to make life easier in the long term.
>
> 4. split the CSS into two files??? one for the standards and one for the
> software specific interfaces, such as the scheduler in livesupport - with
> their own name spaces even
>
> Micz Flor - micz@mi.cz
>
> content and media development http://mi.cz
> -----------------------------------------------------------------
> http://www.campware.org -- http://crash.mi.cz -- http://suemi.de
> "Good job. Hopefully he will go elsewhere..." (Sava Tatic)
> -----------------------------------------------------------------
>
>

------------------------------------------
Posted to Phorum via PhorumMail