search

FrancescoCeruti / linux-show-player

Linux Show Player - Cue player designed for stage productions
https://linux-show-player.org
GNU General Public License v3.0
212 stars 49 forks source link

Some features requests #110

Open aroom opened 6 years ago

aroom commented 6 years ago

Hi, I have some new feature request regarding LiSP

  1. in list mode: it would be great if the selected Cue could stay in the "middle" of the list, and not at the bottom. So you could see which cues are coming next.

  2. something that is really missing: the ability to select more than one cue, for drag and drop. the traditional shift or/and ctrl + clic behavior is really missing

  3. implement shortcuts for all the cue type, not just media cue

  4. the ability to add a new cue after the selected cue, and not always at the bottom of the list

Cheers

EDIT (Francesco) :

FrancescoCeruti commented 6 years ago

Hi

  1. good idea
  2. this require some change in the UI logic, more on this later
  3. we can have a temporary solution for this, but the idea is to have a shortcuts manger that allow to customize and avoid conflicts, plus I don't know what might be used CTRL+<number> ?
  4. mmmh, did you have some suggestion on how to do this? with an entry in the context menu of the cues?

About the 2, what can have is a "next/standby" indicator (like an icon on the left) to identify the cue that will be triggered by the GO (or space-bar), and use the standard selection mechanics for edit/drag&drop and similar.

Like this:

example

aroom commented 6 years ago

Hi, thanks for your answer.

  1. I forgot to mention: it would be awesome to be able to copy/paste or/and duplicate a cue with shortcuts as well. or/and multi-select a bunch of cues and group edit them by loading the same presets in all of them

  2. I'm glad you like the idea

  3. this could be great. But you'll have to implement a behavior to un-select them as well. Standard mechanic (clic on an un-selected cue) would be the best one.

I noticed that you can select and deselect cues with CTRL+Click, but I don't know what you can do with this selection. it seems you can't multi edit them.

  1. a shortcut manager would be perfect. CRTL+<number> seems like a really straightforward solution to me. Usual shortcuts (C - copy, V - past, D - duplicate, delete - delete,...) would be useful too.

  2. for me it would be like this: when a cue is selected (in blue highlight), the normal behavior regarding adding a new cue, or past a cue (if implemented) would always be after the selected cue. If no cues are selected, the new cue would be added at the bottom of the list.

FrancescoCeruti commented 6 years ago

copy/paste or/and duplicate a cue with shortcuts as well.

this should be easy

and multi-select a bunch of cues and group edit them by loading the same presets in all of them

it needs some more work, but can be done

But you'll have to implement a behavior to un-select them as well. Standard mechanic (clic on an un-selected cue) would be the best one.

the un-select is intentionally disabled in the current UI, otherwise it works in a standard way

it seems you can't multi edit them

CTRL+Shift+E or (menu-bar) Edit > Edit selected cues

for me it would be like this: when a cue is selected (in blue highlight), the normal behavior regarding adding a new cue, or past a cue (if implemented) would always be after the selected cue. If no cues are selected, the new cue would be added at the bottom of the list.

seem reasonable :+1:

aroom commented 6 years ago

another killer option that would be awesome : an option to set a minimum time between two go.

this is super useful to avoid double go error.

aroom commented 6 years ago

Hi,

I'm adding here some thought about two behaviors that I find could use some improvement.

In list mode, when you have a config like this:

  1. audio cue
  2. volume cue -10db in 5 sec
  3. volume cue -inf in 5 sec + trig to stop

If you go thru all your effects/cues before the show (like I do to check if everything is alright, regarding the audio medias, and my light cues being triggered by osc via command cue), the next time you gonna fire the CUE 1, the volume is gonna be at 0. or if you fire CUE 1, and then CUE 2, stop the media and go on, when you'll fire the CUE 1, the volume gonna be a -5db.

I had this problem during a show. Firing the CUE 1 and damn! no output: volume at zero...

I think that it would be safer if when we fire Media Cues, the volume is not up to any Volume Cue fired before, but up to the volume that is specifically edited in the Media Cue. or at least give an option to choose which behavior we want, or an option to reset all volume to the volume specified in each Media Cue.

Another behavior with auto-next:

When you have an auto-next, should it be linked with the next cue, and not like now, apply on the selected cue?

If you have an auto-next with a post wait from 5 secondes and you navigate into the list during this 5 second to check or edit other cue, the selected cue will be triggered, not the next cue from where the auto-next was selected.

Sorry to spam you with all those messages, but I'm using LiSP intensively right now, and I thought you'll be interested with some feedback.

By the way, using oscsendyou can easily control any soft with OSC messages. for example I control D::Light (https://getdlight.com) with this message:

GO:

oscsend localhost 7000 /seq/go f 1.0

Fire specific Step ID (here Step ID 12):

oscsend localhost 7000 seq/X2LoadAndFireID f 12

Maybe you could add this into the doc?

Cheers,

FrancescoCeruti commented 6 years ago

I think that it would be safer if when we fire Media Cues, the volume is not up to any Volume Cue fired before, but up to the volume that is specifically edited in the Media Cue. or at least give an option to choose which behavior we want, or an option to reset all volume to the volume specified in each Media Cue.

It should, I'll see to fix this

If you have an auto-next with a post wait from 5 secondes and you navigate into the list during this 5 second to check or edit other cue, the selected cue will be triggered, not the next cue from where the auto-next was selected.

Mmmh, I cannot reproduce this, and it very strange, the implementation explicitly take the cue after the one whose post-wait is finished. Can you try to reproduce it again? and if happen again open an issue with all the details, thanks :)

By the way, using oscsend you can easily control any soft with OSC messages.

Thanks for the hint :+1: