These are comments which have been made during the past month, either to shows
released during the month or to past shows.
There are 29 comments in total.
There are 9 comments on
8 previous shows:
hpr1512
(2014-05-20) "Adopting and Renovating a Public-Domain Counterpoint Textbook"
by Jon Kulp.
Comment 2:
Ken Fallon on 2018-09-30:
"Ahhh so that's what counterpoint is."
hpr1919
(2015-12-10) "DerbyCon Interview with Paul Koblitz"
by Xoke.
Comment 1:
Ken Fallon on 2018-09-27:
"Milkbag wtf"
Mailing List discussions
Policy decisions surrounding HPR are taken by the community as a whole. This
discussion takes place on the Mail List which is open to all HPR listeners and
contributors. The discussions are open and available on the HPR server under
Mailman.
The threaded discussions this month can be found here:
Comment #1 posted on 2018-09-30T12:51:25Z by Ken Fallon
The loop issue
This fails
ls *.mp3|while read i;do ffmpeg -i "${i}" "${i}.wav" 2>&1;done
This works
for i in *.mp3;do ffmpeg -i "${i}" "${i}.wav" 2>&1;done
,/pre>
Comment #2 posted on 2018-09-30T14:00:47Z by Dave Morriss
Re: The loop issue
ls *.mp3|while read i;do ffmpeg -i "${i}" "${i}.wav" 2>&1;done
You don't say how this fails, but there are several reasons not to do things this way:
1. It's unwise to feed a 'while' loop thorough a pipe because the 'while' runs
in a separate shell which can lead to problems
2. Never use 'ls' to get a list of files for consumption in a script. Unless
you can be completely sure that the 'ls' you are using isn't adding suffixes
like '@' for links, and '/' for directories and isn't adding colour codes to
the names, don't do it. Much better to use 'find'.
My test with this pipeline returned colour codes which 'ffmpeg' didn't like,
and it failed that way.
for i in *.mp3;do ffmpeg -i "${i}" "${i}.wav" 2>&1;done
This doesn't use 'ls' it simply uses file expansion therefore no additional
filename garbage!
Did I mention: don't use 'ls' as a way of feeding filenames to a loop or
whatever?
The first example would have worked if you'd written:
The '-maxdepth 1' option prevents 'find' from going into sub-directories. The
'find' is inside a process substitution which is redirected to the 'while' so
the 'read' inside it can obtain what is produced on its STDIN channel.
If I use the real 'ffmpeg' I get (output heavily truncated with only one file shown):
ffmpeg version 4.0.2-2 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8 (Debian 8.2.0-7)
configuration: --prefix=/usr --extra-version=2 --toolchain=hardened
[snip]
libswresample 3. 1.100 / 3. 1.100
libpostproc 55. 1.100 / 55. 1.100
?[0m?[00;36ma.mp3?[0m: No such file or directory
The codes before and after 'a.mp3' are colour on/off codes.
Your environment will certainly be different of course, so your failures may not be the same.
Clear?
Comment #5 posted on 2018-09-30T15:08:27Z by Dave Morriss
Does the comment system remove backslashes?
I actually wrote:
_ffmpeg() { printf "ffmpeg %s %s %s\n" "${@}"; }
but something removed the backslash.
Comment #6 posted on 2018-10-01T11:03:53Z by folky
Material for a show
@Ken and @Dave
Take your comments and make a collaborative show of the material ;-)
Comment #7 posted on 2018-10-01T12:16:59Z by Ken Fallon
touché Sir
touché
Comment #8 posted on 2018-10-01T14:59:05Z by clacke
subshell issues
As Dave points out, the while loop you describe would work if it weren't for ls issues. Here's what doesn't work:
"items" gets updated just fine, in a subshell, and then after the pipe has finished executing, execution continues in the parent shell where the array is still empty.
Null-terminating and giving "read" the appropriate parameters is an HPR episode of its own, no doubt already made by Dave, or in his pipeline. ;-)
Comment #9 posted on 2018-10-01T15:00:26Z by clacke
Kvalificerat hemligt
Excellent pronuncation, Dave! You're spot on.
Compared to "kvalificerat hemligt", "skeptikerpodden" is trivial to say. :-)
Comment #10 posted on 2018-10-01T15:34:27Z by clacke
Re: Intro volume
While it is true that we hosts could do more to manage our sound levels, the facts on the ground are that the intro music is louder than the average show.
I have thought often that the intro volume should be a bit lower, but never said anything.
Comment #11 posted on 2018-10-01T15:36:05Z by Dave Morriss
She sells subshells...
I think I have to do a show on the whole issue of loops in pipelines. It's been in the "topics to cover" heap for a while but now it's being re-prioritised! I'll probably make it show 14 in the "Bash Tips" subset.
Comment #12 posted on 2018-10-01T15:39:43Z by clacke
Re: TTS over intro music
We could still allow people to add arbitrary intros, and just not do TTS-over-intro in those cases. But the idea to do TTS-over-intro on a list of prepared flexible-length intros is really cool.
As for me though, as you have noticed on my shows, I really like having a standardized intro as the unified HPR brand, while allowing some variation at the end.
Comment #13 posted on 2018-10-01T16:43:35Z by clacke
That brings back memories
I never listen to my own shows via the feed, so I never listen to my whistling outro either.
As I hear it now, man does that bring back memories. I remember exactly where I was walking on the way to my bus to work as I was recording it. That was three homes, one country, three offices, three kindergartens and three years ago.
I can feel the chill from the November morning fog around Järfälla Church on my cheeks as I'm typing this.
I know that I accidentally set the sample rate too low when I recorded it (11.25 kHz, I believe), but hearing it now that sound quality is worse than I remember it. :-)
Note to Verbose Commenters
If you can't fit everything you want to say in the comment below then you really should record a response show instead.
Note to Spammers
All comments are moderated. All links are checked by humans. We strip out all html. Feel free to record a show about yourself, or your industry, or any other topic we may find interesting. We also check shows for spam :).