Good evening,
Well, I though it was solved. But something is still awry.... ----- bash.3[ShiPin]: time grope -ob9LHPEaKY Western/.Organ/organ_dir.txt
real 0m0.043s user 0m0.010s sys 0m0.016s bash.4[ShiPin]: time Grope -ob9LHPEaKY Western/.Organ/organ_dir.txt
real 7m15.297s user 1m49.880s sys 0m46.325s bash.5[ShiPin]: alias | grep rope alias Grope='~/myroot/testprogs/Grope' alias grope='~/myroot/testprogs/grope' bash.6[ShiPin]: cat ~/myroot/testprogs/Grope grep -rile $1 bash.7[ShiPin]: cat ~/myroot/testprogs/grope grep -rilIe $1 bash.8[ShiPin]: ----- The results are correct. But notice that the case sensitive search took over 7 1/4 MINUTES; the case INsensitive search took less than 1/20 second. That's a nearly 4 orders of magnitude difference! I would think that the case INsensitive search would involve more processing, and so should take longer. What's going on?
On 3/26/25 4:35 PM, home user via users wrote:
Good evening,
Well, I though it was solved. But something is still awry....
bash.3[ShiPin]: time grope -ob9LHPEaKY Western/.Organ/organ_dir.txt
real 0m0.043s user 0m0.010s sys 0m0.016s bash.4[ShiPin]: time Grope -ob9LHPEaKY Western/.Organ/organ_dir.txt
real 7m15.297s user 1m49.880s sys 0m46.325s bash.5[ShiPin]: alias | grep rope alias Grope='~/myroot/testprogs/Grope' alias grope='~/myroot/testprogs/grope' bash.6[ShiPin]: cat ~/myroot/testprogs/Grope grep -rile $1 bash.7[ShiPin]: cat ~/myroot/testprogs/grope grep -rilIe $1 bash.8[ShiPin]:
The results are correct. But notice that the case sensitive search took over 7 1/4 MINUTES; the case INsensitive search took less than 1/20 second. That's a nearly 4 orders of magnitude difference! I would think that the case INsensitive search would involve more processing, and so should take longer. What's going on?
You've mixed up your option case. -i is insensitive. But both have that. The difference is the -I which means "Grope" is searching all the binary files as well.
On 3/26/25 5:43 PM, Samuel Sieb wrote:
On 3/26/25 4:35 PM, home user via users wrote:
[snip]
The results are correct. But notice that the case sensitive search took over 7 1/4 MINUTES; the case INsensitive search took less than 1/20 second. That's a nearly 4 orders of magnitude difference! I would think that the case INsensitive search would involve more processing, and so should take longer. What's going on?
You've mixed up your option case. -i is insensitive. But both have that. The difference is the -I which means "Grope" is searching all the binary files as well.
You nailed it!... - - - - - bash.11[ShiPin]: time grope -ob9LHPEaKY Western/.Organ/organ_dir.txt
real 0m0.739s user 0m0.012s sys 0m0.023s bash.12[ShiPin]: time Grope -ob9LHPEaKY Western/.Organ/organ_dir.txt
real 0m0.026s user 0m0.013s sys 0m0.013s bash.13[ShiPin]: alias | grep rope alias Grope='~/myroot/testprogs/Grope' alias grope='~/myroot/testprogs/grope' bash.14[ShiPin]: cat ~/myroot/testprogs/Grope grep -rlIe $1 bash.15[ShiPin]: cat ~/myroot/testprogs/grope grep -rilIe $1 bash.16[ShiPin]: - - - - - Using 'I' in both grope and Grope, and 'i' in grope only gives the correct results. The case insensitive search takes longer, which makes sense.
I am indeed wanting the searches to skip the binary files (such as ".png" and ".mkv" files). I am indeed wanting the searches to take case into account.
Thank-you Samuel. It's SOLVED!
home user via users writes:
I am indeed wanting the searches to skip the binary files (such as ".png" and ".mkv" files). I am indeed wanting the searches to take case into account.
Now, try adding more not-letters-and-digits to the search string. It won't be long before things stop working again.
$ echo 'j^k' >z $ grep '^k' z [zilch]
grep can't find '^k' in a file that clearly contains it.
Now, you have to go back to all your scripts and also include the -F option, for this.
$ grep -F '^k' z j^k
On 3/26/25 7:40 PM, Sam Varshavchik wrote:
home user via users writes:
I am indeed wanting the searches to skip the binary files (such as ".png" and ".mkv" files). I am indeed wanting the searches to take case into account.
Now, try adding more not-letters-and-digits to the search string. It won't be long before things stop working again.
$ echo 'j^k' >z $ grep '^k' z [zilch]
grep can't find '^k' in a file that clearly contains it.
Now, you have to go back to all your scripts and also include the -F option, for this.
$ grep -F '^k' z j^k
sigh.
Should I replace the 'e' option with the 'F' option, or do I need both options?
By the way, grep's behavior suggests that the order of the options matters. I did not expect that. Does the order of the options really matter?
home user via users writes:
On 3/26/25 7:40 PM, Sam Varshavchik wrote:
home user via users writes:
I am indeed wanting the searches to skip the binary files (such as ".png" and ".mkv" files). I am indeed wanting the searches to take case into account.
Now, try adding more not-letters-and-digits to the search string. It won't be long before things stop working again.
$ echo 'j^k' >z $ grep '^k' z [zilch]
grep can't find '^k' in a file that clearly contains it.
Now, you have to go back to all your scripts and also include the -F option, for this.
$ grep -F '^k' z j^k
sigh.
Should I replace the 'e' option with the 'F' option, or do I need both options?
No, it's either one or the other. You decide if you want special characters in search strings to be parsed as regular expressions, or not. There's no other option.
On Thu, Mar 27, 2025 at 7:03 AM Sam Varshavchik mrsam@courier-mta.com wrote:
home user via users writes:
On 3/26/25 7:40 PM, Sam Varshavchik wrote:
home user via users writes:
I am indeed wanting the searches to skip the binary files (such as ".png" and ".mkv" files). I am indeed wanting the searches to take case into account.
Now, try adding more not-letters-and-digits to the search string. It won't be long before things stop working again.
$ echo 'j^k' >z $ grep '^k' z [zilch]
grep can't find '^k' in a file that clearly contains it.
Now, you have to go back to all your scripts and also include the -F option, for this.
$ grep -F '^k' z j^k
sigh.
Should I replace the 'e' option with the 'F' option, or do I need both options?
No, it's either one or the other. You decide if you want special characters in search strings to be parsed as regular expressions, or not. There's no other option.
Wouldn't -E allow two different expressions? Something like `grep -E '^k|aaa' <file>`
Jeff
On 3/27/25 5:03 AM, Sam Varshavchik wrote:
home user via users writes:
On 3/26/25 7:40 PM, Sam Varshavchik wrote:
home user via users writes: ... Now, try adding more not-letters-and-digits to the search string. It won't be long before things stop working again.
$ echo 'j^k' >z $ grep '^k' z [zilch]
grep can't find '^k' in a file that clearly contains it.
Now, you have to go back to all your scripts and also include the -F option, for this.
$ grep -F '^k' z j^k
...
No, it's either one or the other. You decide if you want special characters in search strings to be parsed as regular expressions, or not. There's no other option.
Having done some experimenting with both the search string and the grep options, I was able to use both the 'e' and the 'F' options at the same time. The result were correct. The searches were completed quickly. Yet I would not be surprised if some "magic" character could break the search.
Thank-you Sam.
On 3/26/25 8:02 PM, home user via users wrote:
On 3/26/25 7:40 PM, Sam Varshavchik wrote:
home user via users writes:
By the way, grep's behavior suggests that the order of the options matters. I did not expect that. Does the order of the options really matter?
I was paying attention to the options part (and below) of the man page, not the top part that showed syntax. The syntax does suggest, and my testing shows, that the 'e' option must be the last, and must immediately precede the search string.
home user via users wrote:
On 3/26/25 8:02 PM, home user via users wrote:
On 3/26/25 7:40 PM, Sam Varshavchik wrote:
home user via users writes:
By the way, grep's behavior suggests that the order of the options matters. I did not expect that. Does the order of the options really matter?
I was paying attention to the options part (and below) of the man page, not the top part that showed syntax. The syntax does suggest, and my testing shows, that the 'e' option must be the last, and must immediately precede the search string.
I think the man page clearly indicates that the -e option requires an argument:
Matching Control -e PATTERNS, --regexp=PATTERNS Use PATTERNS as the patterns. If this option is used multiple times or is combined with the -f (--file) option, search for all patterns given. This option can be used to protect a pattern beginning with “-”.
It may be specified multiple times, each of which requires an argument, e.g.:
grep -e foo -e bar /path/to/baz
If you're trying to write a generic wrapper around grep, I don't think you'll end up with something that is much (if any) easier to use than grep. To do so, you'll have to learn the grep syntax well enough that you might as well just call grep. :)
Rather, if you have some common use case (or a few), write one or more scripts which work for just those cases and properly handles the arguments needed (including rejecting bogus uses if they can be determined from the arguments given).
In the end, the time spent writing those wrappers is likely to be more than the time spent reading and remembering the grep command syntax.
On 3/27/25 11:40 AM, Todd Zullinger wrote:
home user via users wrote:
On 3/26/25 8:02 PM, home user via users wrote:
On 3/26/25 7:40 PM, Sam Varshavchik wrote:
home user via users writes:
...
I think the man page clearly indicates that the -e option requires an argument:
Matching Control -e PATTERNS, --regexp=PATTERNS Use PATTERNS as the patterns. If this option is used multiple times or is combined with the -f (--file) option, search for all patterns given. This option can be used to protect a pattern beginning with “-”.It may be specified multiple times, each of which requires an argument, e.g.:
grep -e foo -e bar /path/to/baz
Thank-you, Todd. The man page is clear. I was rushed and careless.
If you're trying to write a generic wrapper around grep, I don't think you'll end up with something that is much (if any) easier to use than grep. To do so, you'll have to learn the grep syntax well enough that you might as well just call grep. :)
Rather, if you have some common use case (or a few), write one or more scripts which work for just those cases and properly handles the arguments needed (including rejecting bogus uses if they can be determined from the arguments given).
In the end, the time spent writing those wrappers is likely to be more than the time spent reading and remembering the grep command syntax.
I'm doing the second (common use case), not the first. The help of this list's members in this thread has led to what I need and want.
The use case (for the curious)... I have "link pages" (.html) of links to frequently visited and favorite web sites and pages. I have text files of descriptions and metadata for favorite web pages (example: youtube videos). I was using "find", and am now using "grep" to see where the two sets of files are not in sync. The search strings are youtube video hash keys (is that the correct term?), which can contain dashes and other characters that are neither digits nor letters. If anyone is curious, the search keys in my examples in this thread are for pipe organ performances that I like.
On Sat, 2025-03-29 at 10:31 -0600, home user via users wrote:
The use case (for the curious)... I have "link pages" (.html) of links to frequently visited and favorite web sites and pages. I have text files of descriptions and metadata for favorite web pages (example: youtube videos). I was using "find", and am now using "grep" to see where the two sets of files are not in sync. The search strings are youtube video hash keys (is that the correct term?), which can contain dashes and other characters that are neither digits nor letters. If anyone is curious, the search keys in my examples in this thread are for pipe organ performances that I like.
You might want to look at 'fd', an alternative to 'find' which is very fast and has some additional options. 'dnf info fd-find'.
Also fzf, an interactive directory searcher that has fuzzy matching.
poc
On 3/29/25 11:25 AM, Patrick O'Callaghan wrote:
On Sat, 2025-03-29 at 10:31 -0600, home user via users wrote:
...
You might want to look at 'fd', an alternative to 'find' which is very fast and has some additional options. 'dnf info fd-find'.
Also fzf, an interactive directory searcher that has fuzzy matching.
poc
Thank-you, Patrick.
On Sat, 2025-03-29 at 10:31 -0600, home user via users wrote:
If anyone is curious, the search keys in my examples in this thread are for pipe organ performances that I like.
Classical or another? I've occasionally been able to play real pipe organs (theatre Wurlitzer, and a ~130 year old church one).
On 3/29/25 10:35 PM, Tim wrote:
On Sat, 2025-03-29 at 10:31 -0600, home user via users wrote:
If anyone is curious, the search keys in my examples in this thread are for pipe organ performances that I like.
Classical or another? I've occasionally been able to play real pipe organs (theatre Wurlitzer, and a ~130 year old church one).
Both performances used European church/cathedral pipe organs.
"A. Guilmant - Sonate 1 (Op.42) - III. Final" The organist was Maarten Wilmink "https://www.youtube.com/watch?v=-ob9LHPEaKY" I consider that music classical.
"Pirates of the Caribbean - Davy Jones's theme cover church organ by Grissini Project" The organist was Romain Vaudé. "https://www.youtube.com/watch?v=D-_qS_3KXBA" I don't know if that music is considered classical or not.
What I called "hash keys" usually work in youtube's search, but these don't. Because of the dashes and underscores?
Enjoy!
On Sun, 2025-03-30 at 15:07 -0600, home user via users wrote:
"Pirates of the Caribbean - Davy Jones's theme cover church organ by Grissini Project" The organist was Romain Vaudé. "https://www.youtube.com/watch?v=D-_qS_3KXBA" I don't know if that music is considered classical or not.
It's modern music, so not classical (it has to be old enough). Though it is played in a traditional or classical style.
What I called "hash keys" usually work in youtube's search, but these don't. Because of the dashes and underscores?
I'm not sure they're a "hash" (some symbolic representation of some clip-related data), though I know what you mean. Since people can upload identically titled video clips it has to be something different than a hash of the title. I think they're just a psuedo-random unique ID or serial number generated at time of upload, it's all it needs to be.
For one like https://www.youtube.com/watch?v=-ob9LHPEaKY you can type ob9LHPEaKY into the YouTube search gadget and it will find that clip. And for https://www.youtube.com/watch?v=D-_qS_3KXBA typing just this _qS_3KXBA bit into the search gadget works.
If you shorten them even further, they don't work, so it doesn't seem to be pattern-based search matching. There's something significant about the - and D- prefixes. I don't know why they're different, but for every other clip that I've tried, it's the *entire* thing after ?v=
This is useful for those places that won't let you post URLs, you can tell them to enter those codes into YouTube's search box to see a clip you're referring to. Usually you won't be prevented from typing something like ob9LHPEaKY into things.
A couple of my favourites: V3olBPGLNvc and 1szrllml99M Apart from liking the music, it's also the apparently complete ease that a complex piece is being played.
I'm playing this one: cXoG3cSCYCE
On Sun, Mar 30, 2025 at 11:35 PM Tim via users users@lists.fedoraproject.org wrote:
For one like https://www.youtube.com/watch?v=-ob9LHPEaKY you can type ob9LHPEaKY into the YouTube search gadget and it will find that clip. And for https://www.youtube.com/watch?v=D-_qS_3KXBA typing just this _qS_3KXBA bit into the search gadget works.
If you put the full 11-character "key" in double-quotes in the youtube search field it should work.
There are articles on the web that talk about the "key" - IIRC, each youtube video gets a unique 64-bit integer and the "key" is that integer base64 encoded, BUT, with some characters substituted to make it work within a URL.
Tim:
For one like https://www.youtube.com/watch?v=-ob9LHPEaKY you can type ob9LHPEaKY into the YouTube search gadget and it will find that clip. And for https://www.youtube.com/watch?v=D-_qS_3KXBA typing just this _qS_3KXBA bit into the search gadget works.
Go Canes:
If you put the full 11-character "key" in double-quotes in the youtube search field it should work.
"-ob9LHPEaKY" worked (11 chars), but "D-_qS_3KXBA" (11 chars) didn't, though "-_qS_3KXBA" (10 chars) does.
There are articles on the web that talk about the "key" - IIRC, each youtube video gets a unique 64-bit integer and the "key" is that integer base64 encoded, BUT, with some characters substituted to make it work within a URL.
I read one about it being Base64.
But if you do decode it, whatever scheme they use, all you get is a longer serial number type of string. So I still reckon it's still just a code created on the spot that's probably just a serial number (simply incrementing in some way with every upload by everyone in the world), or a timestamp related value. Either way, it doesn't tell you anything useful.
On Mon, Mar 31, 2025 at 9:56 PM Tim via users users@lists.fedoraproject.org wrote:
Tim:
For one like https://www.youtube.com/watch?v=-ob9LHPEaKY you can type ob9LHPEaKY into the YouTube search gadget and it will find that clip. And for https://www.youtube.com/watch?v=D-_qS_3KXBA typing just this _qS_3KXBA bit into the search gadget works.
Go Canes:
If you put the full 11-character "key" in double-quotes in the youtube search field it should work.
"-ob9LHPEaKY" worked (11 chars), but "D-_qS_3KXBA" (11 chars) didn't, though "-_qS_3KXBA" (10 chars) does.
$ echo -n '-ob9LHPEaKY' | base64 -d base64: invalid input
$ echo -n 'D-_qS_3KXBA' | base64 -d base64: invalid input
$ echo -n '-_qS_3KXBA' | base64 -d base64: invalid input
There are articles on the web that talk about the "key" - IIRC, each youtube video gets a unique 64-bit integer and the "key" is that integer base64 encoded, BUT, with some characters substituted to make it work within a URL.
I read one about it being Base64.
But if you do decode it, whatever scheme they use, all you get is a longer serial number type of string. So I still reckon it's still just a code created on the spot that's probably just a serial number (simply incrementing in some way with every upload by everyone in the world), or a timestamp related value. Either way, it doesn't tell you anything useful.
On 3/31/25 7:00 PM, Jeffrey Walton wrote:
On Mon, Mar 31, 2025 at 9:56 PM Tim via users users@lists.fedoraproject.org wrote:
Tim:
For one like https://www.youtube.com/watch?v=-ob9LHPEaKY you can type ob9LHPEaKY into the YouTube search gadget and it will find that clip. And for https://www.youtube.com/watch?v=D-_qS_3KXBA typing just this _qS_3KXBA bit into the search gadget works.
Go Canes:
If you put the full 11-character "key" in double-quotes in the youtube search field it should work.
"-ob9LHPEaKY" worked (11 chars), but "D-_qS_3KXBA" (11 chars) didn't, though "-_qS_3KXBA" (10 chars) does.
$ echo -n '-ob9LHPEaKY' | base64 -d base64: invalid input
$ echo -n 'D-_qS_3KXBA' | base64 -d base64: invalid input
$ echo -n '-_qS_3KXBA' | base64 -d base64: invalid input
It's "web-safe" base64, so you have to translate two characters. It should also have a "=" at the end to make it 12 characters, but the decoder seems to accept it anyway. However, you're only going to get 7 bytes of binary data. It's not something readable.
echo -n '-ob9LHPEaKY' | tr _- /+ | base64 -d | od -tx1 0000000 fb fa 92 ff 72 97 04
On Tue, Apr 1, 2025 at 12:31 AM Samuel Sieb samuel@sieb.net wrote:
On 3/31/25 7:00 PM, Jeffrey Walton wrote:
On Mon, Mar 31, 2025 at 9:56 PM Tim via users users@lists.fedoraproject.org wrote:
Tim:
For one like https://www.youtube.com/watch?v=-ob9LHPEaKY you can type ob9LHPEaKY into the YouTube search gadget and it will find that clip. And for https://www.youtube.com/watch?v=D-_qS_3KXBA typing just this _qS_3KXBA bit into the search gadget works.
Go Canes:
If you put the full 11-character "key" in double-quotes in the youtube search field it should work.
"-ob9LHPEaKY" worked (11 chars), but "D-_qS_3KXBA" (11 chars) didn't, though "-_qS_3KXBA" (10 chars) does.
$ echo -n '-ob9LHPEaKY' | base64 -d base64: invalid input
$ echo -n 'D-_qS_3KXBA' | base64 -d base64: invalid input
$ echo -n '-_qS_3KXBA' | base64 -d base64: invalid input
It's "web-safe" base64, so you have to translate two characters. It should also have a "=" at the end to make it 12 characters, but the decoder seems to accept it anyway. However, you're only going to get 7 bytes of binary data. It's not something readable.
echo -n '-ob9LHPEaKY' | tr _- /+ | base64 -d | od -tx1 0000000 fb fa 92 ff 72 97 04
It sounds like you are talking about the Base64 URL encoder from http://tools.ietf.org/html/rfc4648#section-5. The character repertoire includes minus ('-') and underscore ('_').
The original Base64 encoder from http://tools.ietf.org/html/rfc4648#section-4 uses plus ('+') and slash ('/').
Jeff
On 3/31/25 10:45 PM, Jeffrey Walton wrote:
On Tue, Apr 1, 2025 at 12:31 AM Samuel Sieb samuel@sieb.net wrote:
On 3/31/25 7:00 PM, Jeffrey Walton wrote:
On Mon, Mar 31, 2025 at 9:56 PM Tim via users users@lists.fedoraproject.org wrote:
Tim:
For one like https://www.youtube.com/watch?v=-ob9LHPEaKY you can type ob9LHPEaKY into the YouTube search gadget and it will find that clip. And for https://www.youtube.com/watch?v=D-_qS_3KXBA typing just this _qS_3KXBA bit into the search gadget works.
Go Canes:
If you put the full 11-character "key" in double-quotes in the youtube search field it should work.
"-ob9LHPEaKY" worked (11 chars), but "D-_qS_3KXBA" (11 chars) didn't, though "-_qS_3KXBA" (10 chars) does.
$ echo -n '-ob9LHPEaKY' | base64 -d base64: invalid input
$ echo -n 'D-_qS_3KXBA' | base64 -d base64: invalid input
$ echo -n '-_qS_3KXBA' | base64 -d base64: invalid input
It's "web-safe" base64, so you have to translate two characters. It should also have a "=" at the end to make it 12 characters, but the decoder seems to accept it anyway. However, you're only going to get 7 bytes of binary data. It's not something readable.
echo -n '-ob9LHPEaKY' | tr _- /+ | base64 -d | od -tx1 0000000 fb fa 92 ff 72 97 04
It sounds like you are talking about the Base64 URL encoder from http://tools.ietf.org/html/rfc4648#section-5. The character repertoire includes minus ('-') and underscore ('_').
The original Base64 encoder from http://tools.ietf.org/html/rfc4648#section-4 uses plus ('+') and slash ('/').
I forgot that it was actually in the RFC. I found the info in various locations including the Mozilla docs. That's what the "tr" command in the chain is for. It converts the URL friendly characters back to the official base64 characters.
On 3/30/25 9:35 PM, Tim wrote:
Thank-you, Tim. (more below)
On Sun, 2025-03-30 at 15:07 -0600, home user via users wrote:
"Pirates of the Caribbean - Davy Jones's theme cover church organ by Grissini Project" The organist was Romain Vaudé. "https://www.youtube.com/watch?v=D-_qS_3KXBA" I don't know if that music is considered classical or not.
It's modern music, so not classical (it has to be old enough). Though it is played in a traditional or classical style.
As I heard in some other youtube video (a science and religion video), English is a mess, and I agree. By "classical", I mean vs. rock vs. country vs. jazz vs. (and so on). I gather you mean vs. baroque vs. romantic vs. (and so on).
... If you shorten them even further, they don't work, so it doesn't seem to be pattern-based search matching. There's something significant about the - and D- prefixes. I don't know why they're different, but for every other clip that I've tried, it's the *entire* thing after ?v=
I groped around the internet, but I didn't find anything about those keys starting with "D-" or '-'. I did find these: "https://dev.to/muhammadsaim/discover-the-magic-behind-youtubes-unique-video-..." "https://webapps.stackexchange.com/questions/54443/format-for-id-of-youtube-v..." Interesting, but they say nothing of '-' and "D-" having special meaning at the start of a youtube video ID.
... A couple of my favourites: V3olBPGLNvc and 1szrllml99M Apart from liking the music, it's also the apparently complete ease that a complex piece is being played.
I'm playing this one: cXoG3cSCYCE
Those were good. For me, some of Rossini's works are fun. Does the church you played in have 2 organs or 2 organ manuals?
home user:
"Pirates of the Caribbean - Davy Jones's theme cover church organ by Grissini Project" The organist was Romain Vaudé. "https://www.youtube.com/watch?v=D-_qS_3KXBA" I don't know if that music is considered classical or not.
Tim:
It's modern music, so not classical (it has to be old enough). Though it is played in a traditional or classical style.
home user:
As I heard in some other youtube video (a science and religion video), English is a mess, and I agree. By "classical", I mean vs. rock vs. country vs. jazz vs. (and so on). I gather you mean vs. baroque vs. romantic vs. (and so on).
Yes, it's an ageist thing. ;-) It has to have come from an era, quite a long time ago, to be called classical. I remember telling someone that I used to like listening to classical music on ABC radio, which I meant the Australian Broadcasting Corporation, they thought it meant Anything But Country. LOL!
Take the music from the original three Star Wars films. It certainly has a classical, almost operatic, style to it. But it's modern era. Although you can find the classic pieces that inspired much of it if you dig around. There were a pair of violinists with a YouTube channel that delved into it (TwoSet, if I remember correctly). It's no secret that was done, it was edited to classical music and the composer was asked to create something similar.
I groped around the internet, but I didn't find anything about those keys starting with "D-" or '-'. I did find these: "https://dev.to/muhammadsaim/discover-the-magic-behind-youtubes-unique-video-..." "https://webapps.stackexchange.com/questions/54443/format-for-id-of-youtube-v..." Interesting, but they say nothing of '-' and "D-" having special meaning at the start of a youtube video ID.
Me, neither. At least it seems that they've been forward enough to create a system that can just use longer UIDs when they've used up all the combinations of an eleven digit code, unlike some other internet address issues... IPv4 & IPv6 fun and pain, anyone?
And speaking of youtube coding, I've always been curious about people who had a hardware display sitting on their desk showing some statistic about their channel (such as a live count of how many subscribers). I've never delved into it, though. I suppose they could just be scraping some of the content of a channels cover page.
Those were good. For me, some of Rossini's works are fun. Does the church you played in have 2 organs or 2 organ manuals?
They've got a variety of instruments. The big organ is a tracker (mechanical linkages between all the parts, no electronics), has two manuals and a pedalboard that seems way too large for one person, it's around 128 years old (we are a fairly young city). They've also got a foot pedal pumped harmonium (I haven't tried it), an upright piano and a grand (I have tried that). I'm not a member, they've just held the occasional open-mike concerts there. I was surprised I was allowed to play it, prior experience in filming weddings for 20 odd years was that they all guard their organs like the crown jewels.
I've also played a computer-controlled using MIDI theatre organ Wurlitzer, but they won't let me upload recordings anywhere with committee approval, and I can't be bothered dealing with that. It's an interesting system, cobbled together in a pioneering way before there were any well-organised (pun intended) projects for computer driving organs. There are some confusing propagation delays with some of the parts, such as a MIDI controlled upright piano, and some other percussive instruments, yet the pipes don't seem to have any delays.
-
Go Canes -
home user -
Jeffrey Walton -
Patrick O'Callaghan -
Sam Varshavchik -
Samuel Sieb -
Tim -
Todd Zullinger