Precord0.9.5 audio recorder

Audio editors, music players, video players, burning software, etc.
Post Reply
Message
Author
mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#91 Post by mcewanw »

tasmod wrote: Older problem is that using window close control instead of quit leaves mp3 playing as arecord is backgrounded.
Oh yes, I forgot to add the lines to fix that; simple to remedy though. The fix will be in the next version. In the meantime, you can just type:

Code: Select all

precord quit
at the commandline, or simply start up another instance of Precord and press the stop button or close button...
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#92 Post by mcewanw »

mcewanw wrote: Oh yes, I forgot to add the lines to fix that; simple to remedy though.
Actually... no it isn't easy to catch that one... Was easy in my earlier wiakrecord because that was a daemon program and the "wiak" client detected the error and sent a clean-up signal. No such solution here. Maybe need a wee daemon running to keep an eye on the running recording. In the meantime, just use close button and if you forget, just start second Precord instance up and press stop... as suggested above. That's one of the reason's I designed the intercomms (IPC) client called "wiak" (written in C) - gtkdialog being a real pain at times like that.
github mcewanw

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#93 Post by mikeb »

I just have case have the
*)
do the same as the exit button for clean quitting

mike

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#94 Post by mcewanw »

mikeb wrote:I just have case have the
*)
do the same as the exit button for clean quitting

mike
Ah... but there is a major difference. The problem here is a gtkdialog one, which occurs for any long running process started from WITHIN gtkdialog; that becomes a child of the running gtkdialog. Unfortunately, gtkdialog, should, but doesn't take its children with it when it dies suddenly by hitting its window X button, so the script which started gtkdialog up waits patiently for any such gtkdialog children to complete before running the final few commands in the driving bash script. Hence, in this scenario, putting 'kills' at the end of the bash script is no solution - in fact, I'd say that the bash script cannot itself directly do anything about the issue ... (it is thus a serious gtkdialog bug since gtkdialog should itself have an inbuilt mechanism to clean up its children on window X pressed).

Your recorder program doesn't start the arecord process from within gtkdialog itself so it is not a child of gtkdialog, just a child of your shell script. The disadvantage with that method is that you have to then restart/redraw the gtkdialog GUI to show your pause button.

That would ruin the Precord interface since gtkdialog doesn't exactly redraw its GUI instantly. To avoid that, I'd have to find some other mechanism to decouple the starting of arecord and so on, such that gtkdialog isn't its ancestor process. One other way out, which I used in wiakrecord, as I said before, is to have the whole main program running as a background daemon, with the GUI only being a client of that (and thus not a parent of arecord). Alternatively, I could also start up some little daemon monitoring program at the same time the arecord or ffmpeg etc process is started, and get that to detect if the gtkdialog suddenly dies (such that the wee daemon can then kill arecord off for me... messy and tricky though).

Maybe, it is best just to live with the "slight" issue, especially since Precord is fortunately able to simply be started up again and still find its children... and can then kill the wee pests. No doubt I'll try and find a solution though (I already tried, but my curiousity/determination forces me to keep trying for a while...:-) Its not worth it to me to waste the current interface as a solution though - if only the author's of gtkdialog would fix the issue at source...

By the way, your wee recorder program suffers from the lesser problem that it leaves lame process running if you close down the app after PAUSE has been pressed (simple to fix though - you need to do a kill -CONT before the final kill -TERM ; I do that in Precord).
github mcewanw

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#95 Post by mikeb »

By the way, your wee recorder program suffers from the lesser problem that it leaves lame process running if you close down the app after PAUSE has been pressed (simple to fix though - you need to do a kill -CONT before the final kill -TERM ; I do that in Precord).
wow thanks for picking that one up...I'd left that at its simple conclusion just with the vu added....so basically one cannot kill a stopped process?

I had no brain the last time I posted and you are doing things in a way that I'm just getting familiar with...one for me to bear in mind.Indeed I have not done anything with gtkdialog for a while and youy reinspired me :) ...now I just need more time :D .
Funny you should mention it but my pburn effort has a separate script that draws /redraws the gui only when there is a change eg a flash stick is plugged in, as detected by the main loop so everything is a child of bash again . The draw back becomes an advantage because when there is a hardware event pmount gets the focus to alert the user...oh the hoops we skip through to please gtkdialog :D

regards

mike

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Eureka?

#96 Post by mcewanw »

<action signal="hide">exit:Exit</action>

Maybe the above will do it, though my initial tests suggest otherwise. It is from Patriot's suggestion re: gtkdialog menubar bug in Gtkdialog Tips (admittedly, Precord doesn't 'have' a menubar, but I was/am hoping Patriot's 'fix' is more universal(?). Whether it is supposed to be more universal wasn't clear to me from what was written in the Gtkdialog Tips thread...):

http://www.murga-linux.com/puppy/viewto ... 899#354192

First test suggests it doesn't work for the issue in Precord: i.e. audio keeps playing on user presses jwm window [X] abrupt close control.

This "long processes keep running" problem seems to be a very long running gtkdialog issue (been plaguing people for years) and one of the major serious 'bugs/issues', which forces all sorts of workaround (like 'having to' redraw the GUI and start the long running processes outside of gtkdialog itself...).

Apparently forum member disciple has written something that may or may not be usefully related, but, alas I haven't been able to find where he wrote it (just a reference from Zigbert to the matter):
zigbert wrote:- Bugfix: Close all dialogs (and PIDs) when pressing 'Emergency Stop' button. (thanks to disciple)
from:

http://www.murga-linux.com/puppy/viewto ... 899#355674

*****However*****, if Patriot's signal="hide" thingy can't be made to do the job (or whatever disciple has written):

I have in fact found another non-gtkdialog method of overcoming the problem, I think... some testing required for certainty (in fact, I might have found two bash-related methods which might sort out the problem once and for all). I'll let the siggies and patties know in the Gtkdialog thread, once I've verified my idea.

What I wrote before is a clue for now(!), but lets hope I don't get run over by a bus, meantime:
mcewanw wrote:Maybe need a wee daemon running to keep an eye on the running recording
(Though I'm still hoping the simple "signal=hide" thingy will be usable instead).

I suppose I should also look at the gtkdialog source code to see what are 'signals' might work (apart from 'hide') - assuming that would reveal that detail.
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Eureka indeed.

#97 Post by mcewanw »

Eureka indeed... Well done Patriot. The following works (a very useful/significant find by Patriot, I'd say):

<action signal="hide">exit:Exit</action>

and the playing audio file is able to stop on window closed abruptly by pressing [X] in top right hand corner (rather than the normal "close" button).

I just need to alter my code slightly and I should be able to upload the new fixed version soon. No need for the other method I'd come up with of monitoring for the child process closing (though I've no idea what action signal="hide" actually does internally... maybe very similar)
github mcewanw

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#98 Post by mikeb »

Nice find....the curve of learning is forever upward :D
So basically child processes from a gtkdialog dialog will behave as such with this added..neat...will be playing with that.
So another example would be alsamixer closing with the window exit I guess rather than needing an explicit kill.

mike

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#99 Post by mcewanw »

mikeb wrote:Nice find....the curve of learning is forever upward :D
So basically child processes from a gtkdialog dialog will behave as such with this added..neat...will be playing with that.
So another example would be alsamixer closing with the window exit I guess rather than needing an explicit kill.

mike
Should be the case, I'd say.

But the technique likes:

gtkdialog3 --program=MAIN_DIALOG --center

but not...

MAIN_DIALOG=$(gtkdialog3 --program=MAIN_DIALOG --center)

though I'm half asleep, so I'm wondering if I'm missing something simple?
github mcewanw

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#100 Post by mikeb »

gtkdialog3 --program=MAIN_DIALOG --center

but not...

MAIN_DIALOG=$(gtkdialog3 --program=MAIN_DIALOG --center)
hhmm getting lost in the bash handling then...I'm tending towards the former anyway....some ways of using gtkdialog make me go crosseyed even when awake

regards and get some sleep

mike

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#101 Post by mcewanw »

mikeb wrote:
gtkdialog3 --program=MAIN_DIALOG --center

but not...

MAIN_DIALOG=$(gtkdialog3 --program=MAIN_DIALOG --center)
hhmm getting lost in the bash handling then...I'm tending towards the former anyway....some ways of using gtkdialog make me go crosseyed even when awake

regards and get some sleep

mike
Hmmm... yes I'd better get some sleep: I'm going cuckoo:

It is the above that works for some reason; nothing to do with signal="hide", which doesn't seem to do anything in this context afterall... I need to rethink what is going on methinks...
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#102 Post by mcewanw »

command substitution [i.e. backticks or $(...)] invokes a subshell, so that must be somthing to do with it. Even caffeine isn't helping at the moment. Anyway, it will be done.
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#103 Post by mcewanw »

Oh well... all that detective work effort when all that was causing the problem was command substitution resulting in gtkdialog being run in a subshell! Anyway, I seem to have it all going properly now, but I won't make a pet of it until tomorrow because my mind is a bit blown now and I'd likely make a hash of it...

Very worth while remembering that though: run gtkdialog in a subshell and long-running processes won't close if the jwm wm [X] button is used to close the GUI... Nothing to do with signal="hide" in this case.

Answer: don't run gtkdialog in a subshell.
github mcewanw

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#104 Post by mikeb »

It's amazing how much effort it takes to come to the tiniest of conclusions :D
Took me several days to fix fonts in puppy 4 and the fix was one additional stanza in font.conf...but worth it....at least answers can be found...something that always bugged me with windows was those unanswered questions

mike

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Uploaded version 5.0.2

#105 Post by mcewanw »

******Latest Version 5.0.2******
# Changes:
# Version 5.0.2: Fixed rec/play processes left running after jwm [X] pressed.
# mp3 vbr now uses combination of minimum bitrate + quality settings to determine compression and quality.
# running VU meter and alsamixer close on exit.
# changed commandline args (run: precord --help)
github mcewanw

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#106 Post by mikeb »

Wow a new version before I get to play with the previous one....... :D

mike

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

The end of Christmas

#107 Post by mcewanw »

Flash wrote: An elapsed time meter or stopwatch that starts with the Record button and stops with the Pause or Stop buttons would be a useful addition for me. :)
Christmas is over.

I intend that no horrible. cpu eating, gtkdialog progressbar kludges for up/down display timers will pollute the simple, but hopefully flexible and reasonably efficient, precord. But note how I use Pschedule as an adjunct to the existing incarnations.

I think you may like the soon to arrive Precord version 6.0.0, even if it does not provide "quite" what you ask for. Actually, in a way, it provides more.
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Precord revolutionary version 6.0.0 about to be uploaded

#108 Post by mcewanw »

Precord 'revolutionary' version 6.0.0 about to be uploaded
But first here is the info you will need to use the added facility:

Well, Precord's automatic add/hide Pschedule button methodology has already been used successfully in the great wee pupRadio app (to hide the Precord button of all things!).

But that was nothing: Precord version 6.0.0 brings a really, revolutionary, much likely to be copied facility (I hate to sound like ttuuxxx, but this is a simple but powerful new approach for extending gtkdialog apps):

slave plugins (external applications) for every major Precord function (all plugins sent an automatic terminate process signal on re-use or quit). So you want a progress bar, or up/down progress timer, or some external VU meter: just add the external app to the appropriate function buttons via the plugin folder facility...

I haven't written any useful plugin as yet (too busy just getting the idea working) but I do supply a simple demo to show how to use it. Here is the blurb from the header file of that (the demo happens to be a simple bash script, but it doesn't have to be):

#**************************************************************************
# Program: PrecordDemoPluginSlave version 1.0.0
# Creation date (YMD): 2009/12/07 (original version 1.0.0)
# Revision date (YMD): 2009/12/30
# (C) Copyright 2009 William McEwan (http://wiak.org)
#***************************************************************************
#
# Changes:
# Version 1.0.0: First version.

# Notes:
#
# To quickly try the supplied demo, rename it in Rox filemanager to
# stopplayslave, run precord, press play and then press stop...
# To stop the stupid popup app, just rename the file back to
# PrecordDemoPluginSlave.
#
# This slave is just a simple demo of how to create a function slave for
# precord. Actually any program can be used for a slave. Indeed, a symlink
# placed in /usr/share/precord to any existing application is a slave, though
# you may find it better to use small shell scripts which call up existing
# applications instead, since that way you can control the termination of the
# called-up applications.
#
# Precord slaves need to be stored in directory /usr/share/precord. The slave
# application, if it exists, is typically loaded on the press of the
# associated function button, or in response to that function being given
# from the commandline (e.g. precord rec outfile.mp3 would check to see if
# there is an executable, or link to an executable, called
# /usr/share/precord/recslave). If there is no such slave, no attempt is made
# by precord to execute it (so you can add and remove slaves as and when you
# like, even when precord is actually running...).
#
# The plugin slave application (or, for example,
# symlink) must be given one of the following names (which match the available
# precord functions):
#
# recslave (which is executed on push of record button, or via commandline call of form: precord rec outfile...)

# stoprecslave (executed on push of the record stop button and/or the quit button etc)

# stoprecnowslave (executed whenever a switch is made between precord small and config GUI's)

# pauserecslave0 (executed on record pause being first pressed, and
on every second press thereafter)

# pauserecslave1 (executed on record pause being pressed the second time, and on every second press thereafter)

# playslave (executed on play selected)

# stopplayslave (executed on stop play selected)
#
# pauseplayslave0 (as per record, but for play)
#
# pauseplayslave1 (as per record, but for play)
#
# quitslave (executed on quit selected)
#
# vuslave (executed on vu/mixer button pressed/selected)
#
# Note that pressing the associated precord button may or may not call up the slave program. The stopplay button, for example, only looks for an associated slave application if an audio file is already playing.
#
# Note that precord automatically, temporarily saves the called up slave application's Program ID, in /tmp/precord, in the form,
# for example: /tmp/precord/PIDrecslave
# However, many applications start up several processes, so it is up to the slave application plugin designer to make sure the slave applications processes are all terminated at the time desired. Precord only sends a simple TERM signal to the first slave process (the plugin designer may need to trap that signal and then ensure all plugin child processes are terminated).
#

# Sorry, this first slave is the ultra in simplicity. It has no useful
# precord-related function (it just pops up an rxvt terminal and displays the date... I'm too busy to write a useful plugin at the moment.
# Forum member Flash would like a simple progress counter; you could write that, for example, as a shell script and call it up, and control it, as per above or you could wait until someone who understands what I am talking about writes it for you.

# Note that, to use this demo, you need to put it in folder /usr/share/precord/, or make a symlink to it from there, and rename it according to which of the above functions you want to automatically call it up (being half a sleep for days now, it took me ages to get it right...).

Have fun, but do realise that the 'tricky' part in writing/using plugins is in keeping track of the process IDs; the supplied demonstration plugin gives strong hints on how to do that.
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

version 6.0.0 uploaded

#109 Post by mcewanw »

By the way, you might imagine that the main precord program has gained a lot of extra bloat compared to the 5.0.2 dotpet size. That is not the case. The dotpet without the demo plugin is less than 400 bytes larger. Indeed the actual demo plugin itself is absolutely tiny (half a dozen lines of bash code); it's just that I've included tons of text documentation in the plugin demo app's header... Precord itself will always be a tiny application, which I intend keeping in the form of one executable script...! :-)

[though I might also write a client/server version, because that coding model can be advantageous when it comes to fast commandline as well as GUI control and usage].

Note that an easier way to test the new plugin system is to simply put a symlink to the PrecordDemoPluginSlave shell script into /usr/share/precord alongside it. If you want the plugin app to popup everytime you press the play button, for example, simply call the plugin symlink "playslave" (i.e. right click /usr/local/precord/PrecordDemoPluginSlave in Rox filemanager and select Link... relative - and name the link playslave).

Being a shell script you can of course get the plugin to start up any number of other apps (and if you copy the technique used in the demo, each and every one of them can be shut down automatically when precord closes, or some other of its buttons are pressed, and so on...)
github mcewanw

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

Automatically terminating the demo with another button...

#110 Post by mcewanw »

Code: Select all

#!/bin/sh
# If you make a symlink called playslave to the demo plugin,
# you could, for example name this simple script here: "stopplayslave"
# You will then find that the demo starts with the play button and
# terminates with the stop button...

kill -TERM $(cat /tmp/precord/PIDplayslave)
Just make sure the script is made executable and placed in /usr/share/precord (and is named "stopplayslave"); and the symlink to /usr/share/precord/PrecordDemoPluginSlave should be called "playslave" and also placed in /usr/share/precord

Hope you get the idea...
github mcewanw

Post Reply