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:

#81 Post by mcewanw »

zigbert wrote:mcewanw
You're doing great development here. Thanks a lot.
I have some suggestions:

1. I personally think that using <combobox> instead of <radiobuttons> for quality and bitrate would simplify the advanced gui.

2. Could you please include tooltips for every button. There is a lot of options I don't know which to pick. abr, cbr or vbr ???? card or device ??? ogg_mm or ogg_q ???? quality N1 ????? quality 00 ????

3. 'date stamped file' now includes a lot of gui. It could be that I'm not getting this right, but wouldn't it be easy to have an option/menu to choose the layout of output filename. User could add her/his default prefix.

4. The advanced gui contains 2 'Quit' buttons ????

5. The <entry> for seconds could be shrunk in width to keep gui clean.
. . .

6. If wanted, it is possible to skip button decoration for some buttons with <button relief="2">
. . .
7. I don't see the point of having 2 pause/stop buttons. I think it could be solved easily with combining some functions:

Code: Select all

. . . [snippits extracted from the structured precord GPLv3 code, as re-arranged and published by Signmund  (mcewanw)]

Sigmund
Thankyou for your criticisms.

Personally I prefer radio buttons to combobox for this application. It is a matter of taste in application design I suppose, so the idea of changing that... egentlig, önsker jeg ikke ä gjöre det... [I've no idea what a google translate will make of that and I couldn't find the symbol for stroke through the 'o', so used umlaut]

I purposively included separate pause and stop controls for Record and Play, after some earlier consideration, because these are two separate functions which I occasionally use separately. I can play a track (listening via headphones) whilst recording something different. I can also play, for example [EDIT] a music-only audio file, and record a voice track whilst it is playing (via mixer). I also use the separate functions when running or controlling precord from the commandline.

Actually, I wish everyone would endeavour to make their gtkdialog/bash apps also runnable from the commandline to at least some extent: that facility automatically provides accessibility (to a visually impaired user for example), and also fits in with UNIX philosophy in terms of allowing programs to be more easily chained together. Of course, you need to re-think your GUI designs to purposively incorporate commandline driving capability, when you want that; admittedly that is one of my interests (and when it comes to GUI's, I'm a one-click radiobox man, by preference, to some extent!)

But, I'm not asking others to write their apps differently; they put the effort into writing them afterall... (though occasionally I might request new features, if they have time and are willing to incorporate them...:-).

I had planned to reduce the duration seconds box, but forgot about it. Thanks for reminding me! :-)
github mcewanw

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

Version 5.0.0 uploaded

#82 Post by mcewanw »

Precord version 5.0.0 uploaded

Changes:

Minor cosmetic alterations.

The Config GUI now also fits on 640x480 screens.

Added some extra tooltips for those who don't know their a(dam) from their e(ve) yet. Not too much additional bloat.
=============

Notes:

For many people, who only have one soundcard (and not a usb one) you probably can ignore the soundcard config checkboxes (unchecked means use plughw:0.0, where 0,0 is often the default sound card). Otherwise just try all the combinations of checked "card, device" until you hopefully find your card (assuming you don't know its location already...). No, I won't be writing a treatise on soundcards :-).

And yes, there are two record and two playback buttons (as before); if, for example, you are recording, the first record button is for recording to the file indicated in the entry to its left. Actually, it is the same for the second recording button (so simple really...:-) but that entry to the left is named automatically to the date of the recording. The tooltips that come up when you hover your mouse over the buttons should keep the vikings amongst you straight.

No I won't be causing yet another menu to open up in order to set whether normal or date stamp recording. I just want to be able to record date-stamped files immediately, as and when required - that's a provided facility! - quick recording of short notes without having to bother entering filenames... The double playback entry slots is another facility: you can have any two files just sitting in there ready to play back - I find it very handy anyway and that's why I wrote the program this way.

Take it or leave it! :-) Anyway, since the program can also be driven/controlled via the commandline, you can write your own scripts to run and control it in any way you want (without having to cut and paste or rearrange any of my code). For commandline usage, start up a console and enter:

Code: Select all

precord --help
But I suggest you try the provided GUI (from Start -> Multimedia -> Precord). I think it is quite handy and flexible.
github mcewanw

User avatar
zigbert
Posts: 6621
Joined: Wed 29 Mar 2006, 18:13
Location: Valåmoen, Norway
Contact:

#83 Post by zigbert »

mcewanw
Thank for this upgrade


Sigmund

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

Version 5.0.1 uploaded

#84 Post by mcewanw »

Latest Version:
***** Version 5.0.1: Bug fix to initialising pause flags, and to stop functions.

One of the advantages of having entirely separate pause and stop buttons is that you can start up two instances of Precord and play one file whilst recording another.

(You can also open a console and use commandline control too... or have any script calling the appropriate precord control commands... If you start precord from the commandline, you can also control that session from the GUI at any time. And of course you can use Pschedule or crontab to start a precord session, in the background, at any time...).

Of course it is possible to combine the two pause and stop buttons for record and play, but then, for example, pause would pause both the playing process and the recording one. For the sake of two extra buttons, I prefer being able to run both simulataneously.

[It is actually very easy to merge the buttons in code though; you don't actually need to cut and paste the related code parts together, as was suggested. Since these are functions, you just need to call them up one after the other at the appropriate time (e.g. a single pause button press would cause the action to call function playpause and then recpause, and so on... but it does pause both play and rec then of course...)].
Last edited by mcewanw on Sat 26 Dec 2009, 14:03, edited 1 time in total.

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#85 Post by Flash »

Mcewanw, for what it's worth, I like Precord's GUI design. Everything appears in one window once I click the config button, rather than options being hidden in drop-down menus or behind tabs. In this case the program is simple enough that there just aren't that many options, so it works well to have them all visible in one window.

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. :)

I tried vbr yesterday and found that it seems to switch the settings from 22050 kHz, 32 kbps, to 44100 kHz, 130 kbps (or something like that.), although still mono. I discovered this by playing a file created with vbr and noticing the properties. Oddly enough, the resulting vbr file is the same size as a cbr file at 22050, 32. The reason for this seems to be that the level is very low. Even though I have Alsa set so that some clipping occurs, when I open a Precord vbr mp3 file in mhWaveEdit, the wiggles are very small. If I tell mhWaveEdit to Normalize the file, then Save it, the file plays much louder with the same volume control settings. The file also becomes noticeably bigger; from, for instance, 11 MB to about 17 MB.

Some mp3 files are so weak that I have to turn the volume of my mp3 player all the way up and even then I can't hear them clearly over the loud music at the gym. I guess now that Normalizing them would make them play louder, but there are so many that it would be tedious in the extreme to use mhWaveEdit for the job. Audio books on CD usually have hundreds of tracks. I'll have to look for a batch Normalizer. :lol:

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

Normalising

#86 Post by mcewanw »

Flash wrote: I tried vbr yesterday and found that it seems to switch the settings from 22050 kHz, 32 kbps, to 44100 kHz, 130 kbps (or something like that.), although still mono.
It is possible to alter the code a bit to allow vbr to go down to lower bitrates, but it would mess up the current code quite a bit and add a bit further bloat, so I don't feel its worthwhile to do that. My code feeds a 44.1 kHz signal into lame which is told to then use vbr at the selected bitrate of 32kB/s, but I notice that it does seem to encode as 44.1kHz regardless - I presume that is just how it works - the average bitrate is probably 32kB/s, hence the same file size as cbr mode?

I do 'cheat' a little bit for ogg_mm encoding: that encoder only goes down to a bit rate of 64kbit/s, so I've just made it that value for any radio box checked below that... Better that, I felt, than a blank recording.

I actually get quite loud recordings, on my system, regardless of the encoder I use. I presume you have your capture input amplitude turned up (and Mic Boost when using a microphone?). Sounds to me like you could do with an external preamplifier; would give better quality than Normalising a low amplitude signal.

As for the GUI... Yes, I'm not about to change that significantly. I often play about with sound recording, and having all the config settings one-click accessible in one window is a major reason for the program existing. The less tabs, menus and comboboxes I have to access to set things up, the better.
github mcewanw

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

#87 Post by mikeb »

[rant] I hate vbr audio , not worth the savings particularly on videos....like we have terabyte drives and 32GB flash sticks, is there any need to use this awkward mode? [/rant]...ooo that feels better.

I made a gui for handbrake.....it only makes xvid and lame avi's cos that what I use and they play with far less cpu than mp4 whilst giving a near dvd quality with no major size penalty (see rant above)...but the point is I won't include any other format as I'm comfortable with it and do not see the point...the coders perrogative.
I like the slim vu meter so I just alter the relevant bit in precord for myself.
Otherwise one ends up trying to make a program that includes the Out house sink trying to please everybody's wants and basic functions get neglected or buried.(seen it happen with other puppy projects)....one must draw one's own line as a general rule to keeps the concept and the result pure.
Indeed making precord a potential building block is a concept that makes sense and one I never thought could be applied to gtkdialog scripts...you learn somethng new every day :)

regards

mike

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

#88 Post by mcewanw »

I will have a look at "Normalising" though, since the lame encoder seems to have options to do that. Don't know when I'll get round to it though; I've got a lot of things piling up that I've got to deal with imminently, so I've been developing Precord with temporary haste, whilst I could.
github mcewanw

User avatar
tasmod
Posts: 1460
Joined: Thu 04 Dec 2008, 13:53
Location: North Lincolnshire. UK
Contact:

#89 Post by tasmod »

Hi, just thought I would report back.

Well, I've had some odd results and no success recording a soundtrack from a youtube flv.

I have managed it in Audacity using the mix control as capture, this however doesn't work for me in precord.
Setting it in Alsa Mixer doesn't work. In Audacity it is one of a dropdown menu entries, it doesn't call Alsa Mixer so maybe that is why it works there.

Playing back a pre-recorded mp3 does so without VU showing anything, also setting any of the alsa controls whilst it is playing does nothing. (It is playing sound and taskbar vol control works)
Older problem is that using window close control instead of quit leaves mp3 playing as arecord is backgrounded. I forget this so I usually just close process.

I have had success with a mic recording though.

I'm sure it's all Alsa related. :(
Rob
-
The moment after you press "Post" is the moment you actually see the typso 8)

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

daemon

#90 Post by mcewanw »

The only problem with using precord from the commandline/other_scripts is that recording takes a couple of seconds to start going. The pause, stop and play work quickly though. I tried a cut down version which didn't contain any gtkdialog inside it, but that made no noticable difference.

Writing the functions in C would probably work (and that would be easy for Precord); the other possibility is to embed it with the capability to run as a daemon, which I'll explore at some stage. [Of course a running daemon occupies memory, but if it is designed to "block" it doesn't actually need to consume any CPU resources until it receives a command to process].

However, a bash/gtkdialog version is relatively easy to maintain (even though gtkdialog can be a bit limiting and painful at times...) and I'm happy enough with the existing model generally.
github mcewanw

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

Post Reply