Silly software wishlist

Using

yt-dlp --live-from-start <URL>

yt-dlp can download a live stream from now or from the beginning but not from an arbitrary point.  The easiest solution is inside https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/extractor/youtube.py

there's a MAX_DURATION variable set to 120 hours or 432000 seconds.  This file is installed in

/usr/lib/python3.10/site-packages/yt_dlp/extractor/youtube.py

You can change MAX_DURATION to any desired number of seconds & --live-from-start will rewind to that time.  It's not accurate to the second.  You can start playing it in mplayer to check the starting time.  Get mplayer to start from later in the stream with mplayer -ss <seconds>

mplayer -ss 999999 makes it start playing live data from the end.

You can also ctrl-c to stop downloading.  It multiplexes the data into a .mkv file.  Helas, if the live stream is still growing, yt-dlp will never stop downloading.

The trick is making MAX_DURATION more conveniently accessed & possibly adding a stop time.

Only 1 stream can be downloaded at a time per python installation.  The fact that all python programs have to be installed in the python system directory is a pain in the ass.

Seeking in the large .mkv files is a buster.  ffmpeg can remux the streams & create an index.

ffmpeg -i "Big Bear Bald Eagle Live Nest - Cam 1 [B4-L2nfGcuE].f140.mkv" -i "Big Bear Bald Eagle Live Nest - Cam 1 [B4-L2nfGcuE].f248.mkv" -c:v copy -c:a copy bald.mp4

ffmpeg -i "Big Bear Bald Eagle Live Nest - Cam 1 [B4-L2nfGcuE].mkv" -c:v copy -c:a copy bald.mp4

The trick is ffmpeg already multiplexes the streams after ctrl-c but it uses mkv by default.  There is a way to make it output a .mp4 with index after ctrl-c.

yt-dlp --live-from-start --remux-video mp4 <URL>

Helas, this generates a .mkv file 1st, then converts the .mkv to a .mp4.  It's just as slow as running the ffmpeg command yourself.  The .mp4 file it generates has corrupted frame durations while the original .mkv has a correct frame rate. 

       count 2 duration 672
       count 1 duration 656
       count 3 duration 672
       count 1 duration 656
       count 2 duration 672
       count 1 duration 656
       count 3 duration 672
       count 1 duration 656
       count 2 duration 672
       count 1 duration 656
       count 2 duration 672
       count 1 duration 656
       count 3 duration 672

The lion kingdom once got good at entering music in Finale by playing the chords while never understanding how the rest of the world mastered dragging & dropping notes with a mouse.  There were still problems, not to mention it was expensive.  The pirated version had a crummy workaround which involved a firewall.  Playback didn't work.

The general idea is to expand on that with a simpler program just focused on capturing notation from played chords.  It would just capture whole notes for the current point in time.  The pitch bender would advance up or down an 8va.  The right pedal would advance a note.  The left pedal would delete the note on the left.

This is a continuation of the ASMR sound synthesizer idea.

https://hackaday.io/project/138050-silly-software-wishlist/log/185030-asmr-sound-synthesizer

This video implanted the idea of an ASMR generator.  Lions worked in offices with white noise generators for years.  They sounded like air conditioning even though the air was off.  There are already ASMR generators.  The mane one the goog is hitting is https://asmrion.com/ but it's junk.  It doesn't really have the relaxing sounds shown by the icons.  The icons have nothing to do with the sounds.

https://asoftmurmur.com/ is another ASMR web app

https://github.com/guzhiling/ASMR is some kind of incomplete program.

https://mynoise.net/NoiseMachines/custom.php?l=30303030303030303030&m=SLEEPINGDRAGON0~SLEEPINGDRAGON1~SLEEPINGDRAGON2~SWEEP4~SWEEP5~ISABELLEKNIGHT6~PEBBLEBEACH6~ISABELLEKNIGHT7~SWEEP7~FOREST9&d=0&title=Asmr%20Lullaby Is some kind of general purpose synthesizer with ASMR samples.

All the sounds are poor quality samples with lots of ambient noise rather than synthetic.  What lions envision is something purely synthetic, to achieve the maximum possible effect.  The mane sounds which work are spray painting, nail filing, female whispering.  There's not much which can be done with the human voice but synthetic machines should be doable.  The sounds would have to be randomized.

Another need is masking the noise of the 3D printer.  That's a job for white noise.

There is a hardware part to this.  There would be speakers next to the bed & some brain dead user interface on a retired phone.  The large speakers are supposed to be consumed as they get smashed.  There are various parts from bluetooth speakers & the speakers in the monitor which never get used.

--------------------------------------------------------------------------------------------------------

Noted none of the drawing programs for tablets make brushing sounds so all these gootubers are making ASMR videos of painting on tablets without the brushing sounds they had years ago & they're not relaxing anymore.  Just a simple app which played brushing sounds from stroking gestures would be a game changer.  There's some challenge in determining if it should play a brush sound or a tap sound.

A tried & true task lions have never done, but which could aid many ideas like pterodactyl models, monocopter gliders, fan enclosures.  Note to try to get started before GPU's are millions of doll hairs.

It would allow video from behind the lion.  It would capture the goggle straps, but it's better than nothing.

Phones finally gained built in screen capturing, but they capture a variable frame rate.  There are various ways to deal with it in the vijeo editor.  The vijeo editor could just handle variable frame rates.  This would be lossless but a major rework.  Playing a file with variable frame rate would require more than adding 1 to the frame number, 23.97 times a second.  It would mean binary searching for a time stamp for every frame played back.  Most of the vijeo files lions deal with are constant frame rate.

For a certain phone app which redraws at 7 to 8fps, there's

ffmpeg -i screen-20220120-164225.mp4 -r 23.97 flat.mp4

The output framerate has to be high enough to get smooth interpolation of the input fps.  Most howto's collect their adsense here & leave off with the crummy quality this produces.  The lion kingdom wanted to change that.

ffmpeg -i screen-20220120-164225.mp4 -c:v h264 -qp 0 -r 23.97 flat.mp4

This sets the output to lossless, -qp 0.  Lions have normally stopped seeing any significant losses at -qp 25.

Sleep mode in Linux works about 90% of the time, but virtualbox is the 1 program which crashes every time.

Suspend with a virtual machine running, resume with the virtual machine running, & your VDI image is gone for good.

 The leading idea is putting all the virtual machines in pause before suspending the host.  There's no way to pause all the virtual machines with a wildcard, but 1 VM at a time can be paused with:

VBoxManage controlvm 'The Grid' pause

In theory, this has to go in /etc/pm/sleep.d/10_virtualbox

#! /bin/sh


case "${1}" in
        hibernate|suspend)
            VBoxManage controlvm 'The Grid' pause
                ;;
        resume|thaw)
            VBoxManage controlvm 'The Grid' resume
                ;;
esac

All those files are run before a sleep or wake.  In reality, there's no consistency in the naming of the hibernate operation, so they have a bunch of random names in the switch statement.  The Virtualbox screen greys out a nanosecond before sleep to show it's working.  A sleep statement would make it more obvious.  

Helas, if the virtual machine isn't running, the script fails & the hibernate command aborts.  Another problem is new lines have to be added for every single virtual machine.

There's

VBoxManage list runningvms

to show all the running & paused virtual machines.

VBoxManage list vms

to show all the virtual machines. 

#!/usr/bin/python

# pause the virtual machines

import os
import sys
import subprocess

command = sys.argv[1]

text = subprocess.check_output(['VBoxManage', 'list', 'runningvms'])
lines = text.split('\n')
for i in range(len(lines)):
    words = lines[i].split(" {")
    if len(words[0]) > 0:
# strip the "
        name = ""
        for c in words[0]:
            if c != '\"':
                name += c
        print("'" + command + "'ing " + name)
        subprocess.call(['VBoxManage', 'controlvm', name, command])

It needs an increasingly sophisticated python script to handle all the corner cases.

Phone plans for the last few years have had different data quotas for tethering & phone apps, but lions have always envisioned a phone app which forwarded packets from ADB or some proprietary USB protocol.  The confuser side relies on user space networking with the tun/tap driver.  The easy phone app tunnels the packets to a server on a wired network, but lions normally only need tethering because they don't have a server on a wired network.  

The hard phone app strips all the headers from the packets & forwards the payloads using android networking calls.  Lions have been writing low level networking code for so long, it might not be as hard as it would have been 20 years ago.  Obviously, no app store would be allowed to distribute such a program & no-one among the current generation is interested in circumventing the system.

The idea got a bit more motivation in the last 2 years because labor shortages have made Comca$t less reliable.  It's become more important to have redundant ISP's.

The lion kingdom found only 1 screencap of adventure construction set running on the C64.  Without deciphering the emulator keyboard & possibly getting the thrustmaster working with the emulator, screencaps were the easiest way to see it.  It's nowhere close to what the marketing suggested for all those years.  It doesn't access anywhere near the limits of the hardware.  They might have limited the room size to 8 sprites wide.  The author said EA renamed it to something other than his preference, but the name definitely conveyed more than it was capable of.

The lion kingdom has no intention of writing a vintage confuser game, but ideas of how a dream game envisioned 40 years ago could have been written have continued to evolve.  Having lower standards is the key.

The lion kingdom realized a general purpose game engine was key, before really knowing the concept of a game engine existed.  The vision was a simple game engine by today's standards which allowed a humanoid player to navigate an open 3D world & fight enemies.  Without even getting to the artwork & programming challenges, which were way above lion level, the mane difficulty was the RAM & floppy disks of the time couldn't store a big enough world or the animations required for fully articulated humanoid players.  That was why games were all 2D side scrollers with very constrained players.

In hindsight, a very simple 2D tiled world with very few unique elements could have emulated the 3D world.  Zaxxon & Blue Max managed airborne & ground game play with only a 2D map with repeating elements.  The world could have been drawn as an isometric projection the way Zaxxon & Blue Max did it, but movement in all directions was essential to make it an open world.  That kind of movement required players to point in 8 directions.  An isometric projection of 8 player directions was quite hard, in those days.

The player animations could have been compressed by compositing 2D body parts on the fly.  Body parts could have been rotated in 90 deg increments, flipped, & translated in 2D.  A gun just needed to rotate down & sideways while a separate leg bitmap could have translated walking positions.  A head bitmap could have just translations.  

Overlaying multiple bitmaps on a single sprite or cluster of 4 sprites might have been fast enough to do in realtime, even if the result looked clunky.  The mane value was just being able to identify a favorite cartoon character.  

Artwork for the player pointing up & down was always the stumbling block.  It was the hardest angle to convey movement in.  The players could have been limited to moving only up right, down left, left, & right.  That definitely constrains how many cartoon scenes could be envisioned in a game.

Cartoons in those days relied heavily on diagonal characters.  Most scenes could be envisioned with flipping.

4 diagonal movements with only sideways facing player graphics are doable, but shooting in all directions could have been difficult with only a side facing player.  Other games just allowed shooting in 1 direction.  It also improved gameplay to not have to precisely aim the gun.

The lion kingdom didn't appreciate 8 Bit Guy's games more because the early ones always looked so bad & were so blocky.  His Planet X games were just simple text graphics with a static, 2D player character.

Petscii robots was originally not impressive, but seeing it make progress on the C64 & then the Amiga showed just how much of the ideal game engine he got.

It actually draws an animated humanoid facing 4 directions & navigating an isometric 2D world, something lions considered really hard 35 years ago & Adventure construction set never got close to.  The blocky motion would be an acceptable compromise for the lack of memory.  The player was just a single sprite overlaid 3 times to get 3 colors.  There might be enough detail in those individual 24x21 sprites to identify a cartoon character.  The pixel size for the player could be doubled without costing memory.

He actually based it on Ultima for DOS, which achieved the same style graphics on much better hardware.

8 bit guy never produced an open ended game engine based on pescii robots or an adventure construction set using his game engine, probably because most of the value was in the game play rather than the graphics.  Something which just allowed a humanoid to navigate a 2D world & shoot things was probably too boring.

0.19 was a big increase in bugs after 0.18.  The ages old shift + middle click bug which causes it to reposition instead of rotate is still there.

The deal breaker is the placement no longer properly loading from a file.  It inverts the axis & angle when loading a file so the angle no longer is the output of the formula.  This causes it to either crash or recompute the wrong angle.

Unfortunately 0.18 can't load anything saved in 0.19.  

The next bug has always been around.  Switch between multiple projects & the model tree always rewinds to the top.

Then, changing projects requires closing & reopening the clipping plane window.