CallerNo6 maybe should have said "could potentially integrate"
2014-04-01 09146, 2014
Freso
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.
2014-04-01 09155, 2014
Freso can dream
2014-04-01 09105, 2014
kepstin-laptop
heh, so a music discovery platform, eh
2014-04-01 09120, 2014
Freso shrugs
2014-04-01 09112, 2014
hawke1
kepstin-laptop: I think recording MBIDs are fine, personally.
2014-04-01 09138, 2014
kepstin-laptop
hawke1: if you have track ids, you can always look up recording mbids. the opposite is not true.
2014-04-01 09148, 2014
hawke1
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.
2014-04-01 09152, 2014
kepstin-laptop
so if you think recording mbids are fine, then track mbids should also be fine
2014-04-01 09102, 2014
hawke1
yes. Track MBIDs would also be fine.
2014-04-01 09108, 2014
hawke1
well, maybe.
2014-04-01 09120, 2014
hawke1
I wouldn't want to track my playcounts by track MBID
2014-04-01 09146, 2014
hawke1
(but some people might, so… :-/
2014-04-01 09153, 2014
kepstin-laptop
the recording would just show the sum of the playcounts of all linked tracks
2014-04-01 09135, 2014
kepstin-laptop
then you get fun stuff like if a recording was mislinked and fixed, the playcounts will magically move to the correct recording
2014-04-01 09151, 2014
hawke1
That would be nifty.
2014-04-01 09118, 2014
hawke1
not sure how reliable track MBIDs are though…
2014-04-01 09133, 2014
danbri joined the channel
2014-04-01 09135, 2014
hawke1
feels like some of the funky things people can do with moving tracks and relinking recordings might do bad things.
2014-04-01 09114, 2014
kepstin-laptop
track mbids are lost if someone deletes a track on a release. if tracks are reordered within a release, the id is preserved.
2014-04-01 09129, 2014
kepstin-laptop
main issue atm is that track can't be moved between media...
2014-04-01 09142, 2014
kepstin-laptop
so that's a destroy/create with a new track id assigned.
2014-04-01 09144, 2014
hawke1
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?
2014-04-01 09104, 2014
kepstin-laptop
hawke1: yes, but I hope such an edit would be downvoted
2014-04-01 09156, 2014
hawke1
could be legit though: make an edit in error, gets passed, someone else notices and fixes it with a different method
2014-04-01 09113, 2014
kepstin-laptop
with a track-id aware tagger, that would cause the files to get reassociated with different recordings :/
2014-04-01 09133, 2014
kepstin-laptop
if that's what you're trying to do, then fine...
2014-04-01 09126, 2014
hawke1
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.
2014-04-01 09134, 2014
kepstin-laptop
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
2014-04-01 09154, 2014
kepstin-laptop
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
2014-04-01 09122, 2014
hawke1
Does anything actually use track IDs yet?
2014-04-01 09128, 2014
kepstin-laptop
not as far as I know
2014-04-01 09144, 2014
kepstin-laptop
obviously I patched picard to save them, but it still uses recording ids for internal matching
2014-04-01 09104, 2014
kepstin-laptop mostly wanted them for vapourware musicbrainz player purposes
2014-04-01 09115, 2014
hawke1
:-)
2014-04-01 09145, 2014
kepstin-laptop
but vapourware musicbrainz player got interrupted by implementing 2048 on my motorola 6809-based trs-80 color computer ;)
2014-04-01 09149, 2014
hawke1
lol
2014-04-01 09108, 2014
Gentlecat_ joined the channel
2014-04-01 09139, 2014
kepstin-laptop is just using a text screen for output right now; making fast graphics code is tricky on a 0.9mhz computer with no accellerated graphics operations
2014-04-01 09150, 2014
kepstin-laptop
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...
2014-04-01 09119, 2014
lidel joined the channel
2014-04-01 09125, 2014
kepstin-laptop
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.
2014-04-01 09121, 2014
hawke1
Yep.
2014-04-01 09124, 2014
kepstin-laptop
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
2014-04-01 09131, 2014
kepstin-laptop
coco*
2014-04-01 09104, 2014
kepstin-laptop
(they made a 4K ram model as well; naturally it simply did not support the high-res graphics modes at all)
2014-04-01 09110, 2014
xplat
heh, good old 8-bit computers
2014-04-01 09138, 2014
xplat
single-ported ram, glitch avoidance left to software
2014-04-01 09121, 2014
kepstin-laptop
actually, the coco had a pretty advanced multiplexer chip (the SAM) for handling access to graphics memory
2014-04-01 09130, 2014
xplat
the C=64 actually had an MMU of sorts
2014-04-01 09144, 2014
xplat
and the C=128 expanded on that by actually having more RAM than could fit in the chip's address space
2014-04-01 09106, 2014
kepstin-laptop
but both the VGD (video singnal generator) and CPU accessed ram via the SAM chip, and it handled synchronizing everything
2014-04-01 09112, 2014
kepstin-laptop
video was basically glitch-free
2014-04-01 09156, 2014
kepstin-laptop
despite being an 8-bit chip, the 6809 actually had 16bit memory addressing
2014-04-01 09103, 2014
xplat
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
2014-04-01 09109, 2014
kepstin-laptop
so the 64K color computer model had direct access to all of ram
2014-04-01 09124, 2014
xplat
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
2014-04-01 09148, 2014
kepstin-laptop
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."
2014-04-01 09115, 2014
xplat
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
2014-04-01 09155, 2014
xplat
GEOS actually used virtual memory
2014-04-01 09112, 2014
kepstin-laptop
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.
2014-04-01 09113, 2014
xplat
(so did the Z-machine interpreter from Infocom)
2014-04-01 09145, 2014
xplat
the C64 had a 'BASIC ROM' and a 'Kernel ROM' which was sort of like BIOS
2014-04-01 09100, 2014
demosdemon joined the channel
2014-04-01 09115, 2014
kepstin-laptop
heh, you only need a ROM with hardware interface routines if you have hardware that needs an interface ;)
2014-04-01 09139, 2014
xplat
the Kernel ROM, like BIOS, made assembly programming a lot easier until you decided you couldn't live with its slowness
2014-04-01 09121, 2014
kepstin-laptop
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.
2014-04-01 09135, 2014
Mineo joined the channel
2014-04-01 09135, 2014
xplat
(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)
2014-04-01 09147, 2014
kepstin-laptop
ah, the CoCo had a parallel disc interface that used the rompack expansion port. could easily run at full disk speed.
2014-04-01 09128, 2014
xplat
commodore's flagship disk drive, the 1541, was actually famous for its slowness
2014-04-01 09144, 2014
xplat
and the cassette drive ... aigh, don't even remind me
2014-04-01 09115, 2014
xplat
it was useless to save a program from a magazine on a cassette since you could practically retype it faster
2014-04-01 09122, 2014
kepstin-laptop
aside from the fact that it used the entire cpu to do software waveform analysis/generating, the coco cassette interface was nice and speedy :)
2014-04-01 09149, 2014
kepstin-laptop
obviously not nearly as fast as a floppy.
2014-04-01 09140, 2014
xplat
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'
2014-04-01 09152, 2014
kepstin-laptop
apparently there were some hard drive interfaces available that used the same rompack interface port.
2014-04-01 09107, 2014
kepstin-laptop remembers frogger taking several minutes to load
2014-04-01 09124, 2014
kepstin-laptop
made a copy of it on floppy tho, that was much faster :)
2014-04-01 09116, 2014
xplat
these days you could record the cassette to a .wav and load it into an emulator faster than 'several minutes'
2014-04-01 09137, 2014
kepstin-laptop
quite true.
2014-04-01 09152, 2014
kepstin-laptop
have to set the emulator back to realtime to actually play the game, of course.
2014-04-01 09131, 2014
kepstin-laptop
the CoCo emulator was actually able to run at pretty much real time on a 486, if I remember correctly.
2014-04-01 09131, 2014
kepstin-laptop
could do some neat stuff with synthesis on the CoCo, since it had no special sound hardware - just a software-controlled 6bit dac.
2014-04-01 09104, 2014
kepstin-laptop
could playback stored samples or do software waveform synthesis.
2014-04-01 09153, 2014
xplat
of course it's pretty hard to run that stuff fast enough for BGM for your game--one problem the C=64 never had
2014-04-01 09157, 2014
kepstin-laptop
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)
2014-04-01 09100, 2014
kepstin-laptop
yeah
2014-04-01 09135, 2014
kepstin-laptop
coco never was a great gaming system :/
2014-04-01 09101, 2014
kepstin-laptop
very powerful, fast cpu, no hardware to let you use said cpu for anything other than running your graphics and sound.
2014-04-01 09123, 2014
kepstin-laptop
could run os/9 and get a real multitasking unix-like operating system, tho, which was kind of neat
2014-04-01 09125, 2014
kepstin-laptop
os/9 had a basic runtime that precompiled to a bytecode; was one of the fastest basic runtimes around for a while :)
2014-04-01 09143, 2014
kepstin-laptop is off!
2014-04-01 09104, 2014
xplat
terrapin logo was basically 'my first lisp machine' but it wasn't known for being very fast (interpreter and GC)
