#musicbrainz

kepstin-laptop: An MBID-aware player might be able to sort on e.g. releases with "download for free" or "purchase for download" releases which have reviews and which have a tag-cloud similar to what you're listening to most. Or perhaps even is rated highly by other people who generally rate stuff the same as you.

heh, so a music discovery platform, eh

kepstin-laptop: I think recording MBIDs are fine, personally.

hawke1: if you have track ids, you can always look up recording mbids. the opposite is not true.

But then I don’t care which specific remaster I listened to, nor whether it was the track 1 or track 7 on a given release when they’re the same.

so if you think recording mbids are fine, then track mbids should also be fine

yes. Track MBIDs would also be fine.

well, maybe.

I wouldn't want to track my playcounts by track MBID

(but some people might, so… :-/

the recording would just show the sum of the playcounts of all linked tracks

then you get fun stuff like if a recording was mislinked and fixed, the playcounts will magically move to the correct recording

That would be nifty.

not sure how reliable track MBIDs are though…

feels like some of the funky things people can do with moving tracks and relinking recordings might do bad things.

track mbids are lost if someone deletes a track on a release. if tracks are reordered within a release, the id is preserved.

main issue atm is that track can't be moved between media...

so that's a destroy/create with a new track id assigned.

like: swap two tracks in the release editor, rename them both so that the release looks the same as before, and swap the recordings…you might be able to swap some track MBIDs, yeah?

hawke1: yes, but I hope such an edit would be downvoted

could be legit though: make an edit in error, gets passed, someone else notices and fixes it with a different method

with a track-id aware tagger, that would cause the files to get reassociated with different recordings :/

if that's what you're trying to do, then fine...

given the stuff that people regularly do as MB editors, either misguidedly or not — I’m not sure how far I would trust track MBIDs, that’s all.

the only case where I can think of where such an edit might be useful is in the case of a mistagged digital release that was fixed after it was added

but the way to do the linking is file → track → recording; if the 'track' is removed due to an edit, that basically makes the file unmatched, and it would have to be heuristically re-matched

Does anything actually use track IDs yet?

not as far as I know

obviously I patched picard to save them, but it still uses recording ids for internal matching

:-)

but vapourware musicbrainz player got interrupted by implementing 2048 on my motorola 6809-based trs-80 color computer ;)

lol

to get good graphics performance, you end up having to write assembly routines to do minimal amounts of updates and page-flipping on vertical refresh...

hmm. would probably want to do it by having one screen buffer be used as a texture source, then do software blts onto other pages, to avoid redrawing stuff.

Yep.

but yeah, the color computer had a simple linear framebuffer, and the screen took 6144 bytes of ram at highest-resolution mode; my coc has 64K total ram

coco*

(they made a 4K ram model as well; naturally it simply did not support the high-res graphics modes at all)

heh, good old 8-bit computers

single-ported ram, glitch avoidance left to software

the C=64 actually had an MMU of sorts

and the C=128 expanded on that by actually having more RAM than could fit in the chip's address space

but both the VGD (video singnal generator) and CPU accessed ram via the SAM chip, and it handled synchronizing everything

video was basically glitch-free

despite being an 8-bit chip, the 6809 actually had 16bit memory addressing

also in the C=128 they decided they had so many expensive ASICs on the board that it was worth installing a second CPU to let you use them from CP/M

so the 64K color computer model had direct access to all of ram

yeah, the C=64 could also have access to all of RAM, although usually you mapped the ROMs and IO into the address space which meant you couldn't get at it all

but yeah, "As an example, the CoCo cassette interface is perhaps one of the fastest available (1500-bit/s) but it does so by literally playing software generated sine waves through its internal 6-bit DAC. While this is happening, the CoCo cannot do anything else as this uses all the CPU time."

terrapin logo didn't use the ROMs and only swapped in the IO chips when it needed them, so it used the full RAM pretty freely

GEOS actually used virtual memory

the only thing stored in ROM in the coco was the basic interpreter; if you're writing assembly your could ignore the roms once the application was loaded.

(so did the Z-machine interpreter from Infocom)

the C64 had a 'BASIC ROM' and a 'Kernel ROM' which was sort of like BIOS

heh, you only need a ROM with hardware interface routines if you have hardware that needs an interface ;)

the Kernel ROM, like BIOS, made assembly programming a lot easier until you decided you couldn't live with its slowness

for some assembly apps, people actually left the basic rom in memory since it had well-optimized routines for drawing commands like lines, circles, etc.

(for the C=64, this usually involved reprogramming the computer and disk drive to implement a faster protocol for data transfer over the serial bus)

ah, the CoCo had a parallel disc interface that used the rompack expansion port. could easily run at full disk speed.

commodore's flagship disk drive, the 1541, was actually famous for its slowness

and the cassette drive ... aigh, don't even remind me

it was useless to save a program from a magazine on a cassette since you could practically retype it faster

aside from the fact that it used the entire cpu to do software waveform analysis/generating, the coco cassette interface was nice and speedy :)

obviously not nearly as fast as a floppy.

my friend had one pretty fun game on cassette. our playflow was 'start loading the tape -> play a game of baseball -> play the video game'

apparently there were some hard drive interfaces available that used the same rompack interface port.

made a copy of it on floppy tho, that was much faster :)

these days you could record the cassette to a .wav and load it into an emulator faster than 'several minutes'

quite true.

have to set the emulator back to realtime to actually play the game, of course.

the CoCo emulator was actually able to run at pretty much real time on a 486, if I remember correctly.

could do some neat stuff with synthesis on the CoCo, since it had no special sound hardware - just a software-controlled 6bit dac.

could playback stored samples or do software waveform synthesis.

of course it's pretty hard to run that stuff fast enough for BGM for your game--one problem the C=64 never had

naturally you couldn't do sound via the dac while doing any cassette oprations, since they used the same DAC (even if CPU was available to do it)

yeah

coco never was a great gaming system :/

very powerful, fast cpu, no hardware to let you use said cpu for anything other than running your graphics and sound.

could run os/9 and get a real multitasking unix-like operating system, tho, which was kind of neat

os/9 had a basic runtime that precompiled to a bytecode; was one of the fastest basic runtimes around for a while :)

terrapin logo was basically 'my first lisp machine' but it wasn't known for being very fast (interpreter and GC)

and it's still april fools in america...