Wanting to port an MP3 jukebox (seeking contract programmer?)
Posted: Sun Aug 28, 2016 3:33 am
Hi,
I have been wanting to run one of the many MP3 'jukebox' type players on Kolibri for many years now. But nothing has ever come up.
I used to have MPXplay set up on a DOS computer, but found the lack of support for almost everything extremely frustrating.
I chose DOS because:
- Exceptionally fast boot time. The computer takes longer doing BIOS checks than getting DOS up and running.
- Lack of bloat (related to the fast boot time, but also means I can use a small hard disk).
- AND THE BIGGEST PLUS : It can be turned off *without* notice. None of the shutdown procedure that 'doze and many nixs' require.
I really dislike DOS because:
- Long file name support is buggy no matter what LFN utility is used (I tried them all, and they all have bugs of one sort or other).
- No proper USB support (yes, USB drivers are available for DOS, but like everything in DOS they are not time-sliced, so access to USB audio files chops the audio output into short stuttering bursts).
I looked at minimalist linux distros (eg: puppy) but they are still very large (>40MB), take a long time to boot, and (puppy at least) requires a shutdown procedure. If not shutdown properly, it brings up a warning on next boot.
I considered using DOSbox on Kolibri so I could get USB, even if LFN was still broken. However, after trying it I determined I would need a stupidly fast PC to run an emulator without getting audio breakup... I want to run this thing on a fanless PC at preferably slower than 500MHz. I needed well over a GHz to get smooth audio, and that meant DC powered (eg: battery powered) PCs were out unless I wanted to spend some serious cash. And besides, I would still need to use DOS, which I will put up with, but really dislike.
So, I got the source code for a basic MP3 'jukebox' style player written in assembler (MPR). I also considered porting an earlier MPXplay to Kolibri. MPXplay has now moved to 'doze, which in my opinion *reduces* its' appeal. But in the years I've had to do this, I've never had the time to devote to a port, and realistically I don't have the skills either (I've done lots of coding for micro-controllers, but none for mainstream computers).
I would like to ask if anyone else has an interest in doing a port of either these players (MPXplay is in C, MPR is in TASM - I think), and if so, I am willing to contribute financially for someone with better programming skills than me to do the work.
I like the look of Kolibri, and I like what it can do (it supports several audio cards - much more than DOS, supports multiple screen resolutions, USB, a few file systems other than FAT, and much more). MPXplay and MPR both have their own advantages & disadvantages. MPX has a better interface and supports more audio formats. MPR is really small and already in assembler (which would appeal to many 'hard' Kolibri fans).
Please comment on this thread if you are like me and have an interest, and if you could/could not/would not contribute towards someone to do the work, or comment if you are interested in the actual doing and we'll move detailed discussion to PM.
Cheers,
MM.
I have been wanting to run one of the many MP3 'jukebox' type players on Kolibri for many years now. But nothing has ever come up.
I used to have MPXplay set up on a DOS computer, but found the lack of support for almost everything extremely frustrating.
I chose DOS because:
- Exceptionally fast boot time. The computer takes longer doing BIOS checks than getting DOS up and running.
- Lack of bloat (related to the fast boot time, but also means I can use a small hard disk).
- AND THE BIGGEST PLUS : It can be turned off *without* notice. None of the shutdown procedure that 'doze and many nixs' require.
I really dislike DOS because:
- Long file name support is buggy no matter what LFN utility is used (I tried them all, and they all have bugs of one sort or other).
- No proper USB support (yes, USB drivers are available for DOS, but like everything in DOS they are not time-sliced, so access to USB audio files chops the audio output into short stuttering bursts).
I looked at minimalist linux distros (eg: puppy) but they are still very large (>40MB), take a long time to boot, and (puppy at least) requires a shutdown procedure. If not shutdown properly, it brings up a warning on next boot.
I considered using DOSbox on Kolibri so I could get USB, even if LFN was still broken. However, after trying it I determined I would need a stupidly fast PC to run an emulator without getting audio breakup... I want to run this thing on a fanless PC at preferably slower than 500MHz. I needed well over a GHz to get smooth audio, and that meant DC powered (eg: battery powered) PCs were out unless I wanted to spend some serious cash. And besides, I would still need to use DOS, which I will put up with, but really dislike.
So, I got the source code for a basic MP3 'jukebox' style player written in assembler (MPR). I also considered porting an earlier MPXplay to Kolibri. MPXplay has now moved to 'doze, which in my opinion *reduces* its' appeal. But in the years I've had to do this, I've never had the time to devote to a port, and realistically I don't have the skills either (I've done lots of coding for micro-controllers, but none for mainstream computers).
I would like to ask if anyone else has an interest in doing a port of either these players (MPXplay is in C, MPR is in TASM - I think), and if so, I am willing to contribute financially for someone with better programming skills than me to do the work.
I like the look of Kolibri, and I like what it can do (it supports several audio cards - much more than DOS, supports multiple screen resolutions, USB, a few file systems other than FAT, and much more). MPXplay and MPR both have their own advantages & disadvantages. MPX has a better interface and supports more audio formats. MPR is really small and already in assembler (which would appeal to many 'hard' Kolibri fans).
Please comment on this thread if you are like me and have an interest, and if you could/could not/would not contribute towards someone to do the work, or comment if you are interested in the actual doing and we'll move detailed discussion to PM.
Cheers,
MM.