evandelisle / showq Goto Github PK

Does not do the expected fade and occasionally causes a crash

Suggestion: The main window of ShowQ is clear and functional, but there are things that can be improved:

• Keep "Type" and "Auto cont" slim: There seem to be no reason why the "type" and "auto-cont"-columns are variable at all. A fixed width could keep them from stealing space from the other columns.
• The width of "Description" and "Cue No." should automatically orient on it's content.
• Column "Wait" and "Q Elapsed" should default to a certain minimum-width and get wider, if "Description" and "Cue No." allow it.
• Keep the possibility of manual configuration.
• Right click on the column-names could open the same dialog as the "view"-menu (or could even replace the latter).

I don't know if it's easy to do, but i think it would be better that only the last cue is stopped with ESC and not all Cues. In all the years i used showq for my theaterwork it happened two times that i did a double-go with the space bar. In this case my proposed behaviour would be more useful. (Human error).

In commit 75dc2ea trigger hotkeys made up of single letters eg x working again.

Would be great, if all relevant information could be checked in the main window.
What's missing:

Routing and fader-info of wave-cues
Relation infos of stop-, start-, pause- and fade-cues.

Maybe both could be shown in a new "info" column, f.e.

I have a cuelist with about 5 Fadeout-cues. The first is working correctly, the target-field can be changed and is persistent. From the second Fade cue on, fades are done on any running wave cue, and is not refering to the target cue, because all the targets are defined to 20 (or 1 if you use renumber). Which means that my fade out cue Nr.5 will fade any running wavecue but it is supposed to fade out the 5th wavecue.
EDIT: This happens probably only with cuelists which have been created with an older version of showq. Just relinking to the wavefile (the field wave is empty when you open an old cuelist) is not enough, you need to delete the cue and recreate it. Or probably start from scratch.

reference at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783217

When ShowQ is set to load a session on start up and it has been deleted it looks like nothing has happened. Saving uses the original session file name and not acting like a new show.

Build instructions mention that gtkmm is required, but the build script requires version 2.4.

The build instructions should make this more clear as (at least in Ubuntu 16.04) there are multiple verisons of gtkmm available (2.4 and 3.0)

It would be very useful to have the name of the showfile in the bar on top rather than the name you give in the properties window.

(from http://sourceforge.net/p/showq/tickets/5/ )

For example having one wave cue and an autocontinued fade cue, when editing the wave cue, sometimes the fade cue won't autocontinue anymore. Saving the show and restarting showq solves the issue.

(from http://sourceforge.net/p/showq/tickets/3/ )

When drag'n'drop, you get ugly words when using non-english characters.

Editing a cue that has been added with drag and drop causes a new cue to be added

Hey, it's not a bug, it's a feature!

Haven't tried this with other audio-files not supported by showq, but if you try to import a m4a-file (no matter if drag n drop or using edit -> new cue -> wave cue, showq crashes. Would be nice, if showq says "not supported" insteas of crashing... :)

Build from today's GIT 4700ddc , the build is going fine, but when trying to launch showq, I've got:

$ showq
ShowQ:out_1 # system:playback_1
ShowQ:out_2 # system:playback_2
ShowQ:out_3 # a2j:Midi Through [14] (playback): Midi Through Port-0
ShowQ:out_4 # PulseAudio JACK Source:front-left
ShowQ:out_5 # PulseAudio JACK Source:front-right

Then, when clicking on the OK button, nothing happen but showq finishing.

@evandelisle : let me know if I could provide any other information.

Setting the target to a cue fails and also is not saved

Assuming here that ShowQ is gtk2 based (which might not be right - if so, please tell me).

If I understand correctly, Debian is going to remove all software depending on gtk2 for the next stable (named "buster"). I'd be great then to transition ShowQ to gtk3 in order to keep it distributed in the Debian repo with the next stable.

Moreover, Debian removing gtk2 support sounds like gtk2 is dying, hence other distributions will (or have already) probably take the same way.

The progress indicator when a wave cue is playing back goes past 100%, causing GTK*Warning prints, and bad user-feedback.

Compiling showq on manjaro (arch) needs some adjustements:
Pointing to python2 (instead of python, which will call python3) in two files:
/waf and /src/wscript
and change the last line of /src/wscript to
'-DPROGRAMNAME_LOCALEDIR="${PREFIX}/share/locale/"', '-std=c++11']
)

With jack-transport-support you could sync xjadeo, ardour, blender and other cool stuff with ShowQ.

A jack-transport cue could look similar like the other cues with the following riders:

Info
Trigger
Transport: A start-time, a stop-time and a possibility to check the settings, f.e. a little player like in the "wave" rider of the "wave-cue". Two times, first one absolute time of jack-transport, second one time of the cue.

Of course: Can just be used with jackd can't be used with ALSA.

Safe some space…

Fade times having values after the point are not saved correctly. 0,5 sec is saved as zero, 3,2 sec is saved as 3 sec. Manually editing the xml-file is possible, fade times are recalled correctly as long as the file isn't saved again.

( from http://sourceforge.net/p/showq/tickets/1/ )

To reproduce: Take a bunch of (f.e. 10) samples and drag'n'drop them into ShowQ. Activate auto-cont in all but the last entry. Start the first cue.

Expected behaviour: All wave-cues are playing.

Most likely, some of the wave-cues won't play.
If you deactivate auto-cont and try to play one after another wave-cue you will experience that the same wave-cue(s) that refused to play in the test before only work if another wave-cue is finished. Which one prevents the wave-cue from playing is unpredictable.

To fix this: Just re-import the sample and create another wave-cue.

Suspicion: Only happens when drag'n'drop?

A strange thing happens when renumbering the show. All cue id's and target id's are set to 0. But looking at the xml-file shows that renumbering works a bit. The fourth (fade)cue in my list, which was before cue id 7, targeting cue 5, now reads:

<cue_id>0</cue_id>
<Fade target="3" .....

( from http://sourceforge.net/p/showq/tickets/4/ )

You should be asked if you want to save changes (if any were done to the show). Now the behaviour is that showq closes regardless of changes.

( moved from http://sourceforge.net/p/showq/tickets/6/ )

• Assign a hotkey to a cue.
• Save session.
• Quit program, restart, restore session
• Hotkey is now disabled.

Simple yet important missing feature :)

As far as I understand it, there is no way provided right now to provide Showq with a translation.

I'd be great if it could be done, I'd suggest using gettext which is well know, well spread, and well used across a wide range of Libre Software.

If/when the system is implemented in ShowQ, I'd then be willing to provide with a French translation.

Cheers.

Its not really about latency. When you start three wavefiles in the same moment with autocontinue, the second and the third will be played later then the first one (something like a quarter or a half second).

A workaround is taking a short wavefile and autocontinue other wavefiles after that. The first wave is not audible, all other wavefiles started with autocontinue are in sync. The drawback is a little delay when starting the cue.

(from http://sourceforge.net/p/showq/tickets/2/ )

Regression: Since debian version 0.4.1+git20090622+dfsg0-2 ShowQ can only playback samples with the same samplerate configured in the jackd-server.

While writing this report (28.03.2016) showq won't start on a basic debian testing installation.

ShowQ prints error message
"showq: symbol lookup error: showq: undefined symbol: _ZN4Glib9file_testERKSsNS_8FileTestE"
and exits.

(According to Harry van Haaren) this is most likely a problem with the GCC-5-ABI-breakage.
Installing kxstudio-repositories and dist-upgrade to the libraries offered there is a possible workaround.

[Edit: Typo]

If a fader-cue is interrupted by the escape-key, it won't react next
time it's triggered. Other cues, also fader-cues which are not
interrupted by pressing the escape-key, continue to work as expected.

Reported on Debian bug-tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705898

Hello,

I would like to try SHOWQ on my ubuntu 16.04 distribution but the ./waf configure give

Logged from file Logs.py, line 167
Checking for 'g++' (C++ compiler) : /usr/bin/g++
Checking for program 'pkg-config' : /usr/bin/pkg-config
Checking for pkg-config version >= '0.0.0' : yes
Checking for 'gtkmm-2.4' : yes
Checking for 'gthread-2.0' : yes
Checking for 'libxml++-2.6' : yes
Checking for 'alsa' : yes
Checking for 'jack' : not found
The configuration failed
(complete log in /home/bruno/Téléchargements/showq/build/config.log)

When i'm looking in the " config.log " file, i can read this at the end :

Checking```for 'jack'
['/usr/bin/pkg-config', '--cflags', '--libs', 'jack']
err: Package jack was not found in the pkg-config search path.
Perhaps you should add the directory containing jack.pc'
to the PKG_CONFIG_PATH environment variable
No package 'jack' found

not found
from /home/bruno/Téléchargements/showq/src: The configuration failed

Can you give me some help please ?
I always installed JACK and used it with Ardour ou LISP without no matter.

Thank you
Bruno

Hi all,
I'm glad to see that finally I found back this little thingy and that it's currently active. Kudos.
Maybe you guys could know where I can find some documentation about using it? ("you can read the source" is not an expected answer :) )
Cheers,
Olivier

ShowQ crashes in the following case:

• Create a show and save it
• Quit ShowQ
• Delete the saved show
• Start ShowQ - ShowQ wants to open the last session but it
  fails. For the user it looks like it's a new session
• Press "save" -> Crash! - ShowQ wants to save in the file which
  doesn't exist anymore

Expected behaviour: When started the second time, ShowQ should pop up a
message like "Didn't found the last session. Started a new one." When
pressing "save", ShowQ should behave like pressing "save as" - the
default behaviour on new sessions.

As per Debian bug-tracker report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783217