MIDI & Sequencers for the 8-Bit

[+mytek]

1 hour ago, flashjazzcat said:

I kind of soured to the whole thing after I damaged my populated 1088XLD board by powering it up with the 5 and 12V regulators swapped, and I've had no opportunity or inclination to invest more time in trying to fix that yet.

Well unfortunately I also wasn't able to help you get that resolved with a shipment of new chips due to my financial picture changing.

 

2 hours ago, flashjazzcat said:

I do intend to build support for 'external' file handlers into SIDE3 (so that anyone could write a player module for any file type they like), but there's no code space for such things in the SIDE2/XEL Loaders. And I don't have time - even with the noblest of intentions - to create and maintain a separate stand-alone player for multiple hardware platforms.

It would seem like you've already got a pretty good chunk of what would be needed to create a MIDI player in the existing PDM player. Too bad someone else couldn't step in to do that. And yes I do understand that you don't like the multiple version support to have both the PDM and MIDI player based versions available. And lastly if it would have been possible to handle this in a similar way to your Plug-Ins, then the base code of the BIOS could have been kept independent, with a user simply selecting a given player to add to it during an update. Hindsight is a bitch

 

2 hours ago, flashjazzcat said:

Unfortunately I've been working on SIDE3 stuff 100 per cent of the time for the past two and a half years, with no end in sight.

Well I sure hope you are being compensated by Lotharek for this

 

Seems like it became the never ending story, pushing all other concerns to the wayside. I wish you well with your journey.

 

[flashjazzcat]

27 minutes ago, ivop said:

Does SpartaDOS X Commander support launching commands based on the extension of a file? In that case, you already have your file selector.

I believe so. The intention is to do the same thing in the SIDE3 loader, and anything which works with one should work with the other.

24 minutes ago, mytek said:

Well unfortunately I also wasn't able to help you get that resolved with a shipment of new chips due to my financial picture changing.

I quite understand, and don't think for a moment I was hanging on waiting for you to bail me out. It's a time problem, not a financial problem. I really appreciated your offer to help me fix my dumb mistakes, nevertheless.

24 minutes ago, mytek said:

It would seem like you've already got a pretty good chunk of what would be needed to create a MIDI player in the existing PDM player.

Yes, but that's a mess and is currently hard-coded for IDE devices. In October 2019 or so, I took the existing SIDE/XEL loader and began turning it into the SIDE3 loader. A year later, in September 2020, the hardware was released and I just managed to get a loader ready in time, and - nearly two years later - I have only now reached the point at which I can offer something with 'version 1.0' written on it.

24 minutes ago, mytek said:

Too bad someone else couldn't step in to do that.

I can barely keep track of the already enormously complex PDM Player (which was cobbled together from a loader which was - for years - aggressively coded for compactness at the expense of maintainability), and the SIDE3 player (to which I can at least apply something approaching coding standards, thanks to enormous ROM capacity) currently comprises 45,000 lines of assembly language source code. None of this is open-source, either, although I have no objections to offering technical assistance to other developers who fancy writing a client applications for the SIDE3 loader, or indeed a stand-alone player written from scratch.

24 minutes ago, mytek said:

And lastly if it would have been possible to handle this in a similar way to your Plug-Ins, then the base code of the BIOS could have been kept independent, with a user simply selecting a given player to add to it during an update.

This has always been the plan, but if third-party take-up with SIDE3 file handlers is anything like third-party U1MB BIOS plugin development, we'll get perhaps one offering in the space of seven years.

24 minutes ago, mytek said:

Well I sure hope you are being compensated by Lotharek for this

To some extent, yes, and this forms a measurable (if wildly varying) part of my monthly income. With that in mind, and as a self-employed individual, I am obliged to prioritise those projects which generate regular income. Whether this is an effective way to derive an income, and whether said income is commensurate with the amount of work carried out is another matter entirely.

24 minutes ago, mytek said:

Seems like it became the never ending story, pushing all other concerns to the wayside. I wish you well with your journey.

I had the file system drivers (even the long filename FAT driver, written from scratch) more or less up and running after about 6-8 weeks last summer (as evidenced by some forum posts), but producing file system drivers which are well-tested and fit for mission-critical use is quite another matter, and it takes months. And that's not counting the massive amount of additions to the loader itself (which you can see in a video which will be released shortly), which caused the code (when compared to my original SIDE/SIDE2 loader) to quadruple in size. 'Regular' repair/renovation/upgrade work was almost non-existent for the latter half of 2021, meanwhile, so I become totally dependent on firmware revenue for a while, and this was around the same time that my father died and my mother became entrenched in full-time residential care. Oh - I had to wage war with the HR department of my wife's employer several times last year, as well, and again in January 2022, but at least that was concluded before I started having neighbour problems which caused me and Deborah to start searching for a new house. 

 

So yeah: I think doing such a lot of coding and technical writing, etc, has (possibly) kept me sane.

 

Thanks so much, anyway.

Edited June 28, 2022 by flashjazzcat

[rcamp48]

3 hours ago, ivop said:

I understand. You have enough on your plate already

 

That sounds pretty cool

 

I was thinking, once there's a proper CLI player, a TUI could easily put on top of that. Even load the player after the file is selected. Does SpartaDOS X Commander support launching commands based on the extension of a file? In that case, you already have your file selector. Just the CLI player has to be done

 

---

 

As for MIDI support in Altirra, it is only half finished. There's only MIDI OUT, no MIDI IN. So, no MidiTrack III for you!! (soup-nazi voice)

 

Then there's Wine, which also has a half baked implementation of MIDI, but most of the time I manage to bridge the Alsa MIDI THROUGH to JACK and use FluidSynth or real hardware from there. Getting MIDI IN to work with Wine is a nightmare IMHO, so for Windows MIDI programs, I would use VirtualBox (downloading WinDev2204Eval.VirtualBox.zip from Microsoft as we speak, because of reasons that'll soon be clear in another post ).

 

I have something that automatically shortens MIDI filenames , and I am getting better results with Spartados 3.3B, unfortunately a lot of midi files are bad for some reason, there is a way of importing them with Altirra but it is slow and tedious but it does work, also I have got the playback from the PC to register on the Atari with recmidi.com , and using midi thru I am able to hear the midi that goes into my Atari and then out from the Atari into my keyboard and then out from the keyboard into my stereo system, will take a few pics of the entire setup

 

[+mytek]

40 minutes ago, rcamp48 said:

I have something that automatically shortens MIDI filenames

Although that probably is useful when limited to 8 characters, there's no way it can convey anywhere near the information of the original name no matter how it's abbreviated. For this reason long file name support really should be cooked into a new player from the get go.

 

[rcamp48]

When you record music on the Atari you can put text in that will tell the name of the song, although that is only for stuff recorded with recmidi. Here is a 10 minute video that shows how to do this.

 

Recording MIDI from PC to Atari with RecMIdi

[rcamp48]

8 hours ago, Stephen said:

I'm not aware of anything better unfortunately.  I wonder if the source to the existing player is out there so development could continue?

I don't know if this email works or not but on my screen it says ixkuczek@kki.net.pl

 

[rcamp48]

Ok I tried , the email comes back, I thought so, but the name of the person is Ireneusz Kuczek from Poland , I will get in touch with my friend Piotr in Poland and see if he can get in touch with this person for me.

 

[+mytek]

18 minutes ago, rcamp48 said:

When you record music on the Atari you can put text in that will tell the name of the song

Yes you can see that in the current Midi-Play v1.3, but not very useful when you have a 100+ files you wish to sort without playing each and every one first. Having the file name give the important parameters really is the best way to go.

 

[rcamp48]

Well here is a start , the disassembly of MIDIPLAY 1.3, I used a program on the web to disassemble it.

 

midiplay.asm 

 

Don't know if it is correct, but its a place to start anyway.

 

[rcamp48]

I just had a thought , all you have to do is load MIdiplay under MyPicoDos 4.06, it loads perfectly but bombs after loading the directory, MyPicoDos already supports long filenames.

 

[rcamp48]

Here is a directory with sub-directories in it, it already displays as long file names all you have to do is tweak Midiplay a bit to handle the long filenames and since MyPicoDos already supports long filenames the next step is to load the fienames , as you will see MIDPLAY loads in MyPicoDos, but gives an error 130 at getting a directory BUT it does not bomb totally it just comes back to the screen for Midiplay 1.3

 

Here are the three 16 meg ATRs that I have already created.... someone can have a go at it, and you already have a disassembly of the program. 

 

MIDI_Files_1.ATR

MIDI_Files_2.ATR

MIDI_Files_3.ATR

 

Note that these files will load Midiplay but not the directory

[ivop]

40 minutes ago, rcamp48 said:

but gives an error 130

That means that after MyPicoDos loaded the binary, there's no D driver, i.e. a DOS, to load the MIDI file from disk.

 

(Sorry for the D, but the forum software kept changing D   :     to ?   (stupid imoji) whatever I did.

I hate smurfs software that "thinks" for me )

[rcamp48]

That makes sense , I am working on a MyDos version with 28 sub-directories, alas short filenames

Mydos will work with Midiplay

 

Uh that is 3 disks 16 MB with 14 sub - directories... I hope I get no 'bad midi files'  in this one.

 

Edited June 29, 2022 by rcamp48

[+mytek]

Another thing to mention that is quite annoying about Midi-Play V1.3, is the fact that it needs to fully load the MIDI file from disk into memory before playing it. A better method would be to only load just enough to get the song playing, and then continue loading the rest on the fly, providing the option to abort at any time. Since the MIDI device is on the SIO bus in an unconventional way, this concurrent operation of file loading and playing the song might not be possible via an SIO drive. However if using something like the AVG, UNO, SIDE, ect. it should be okay.

 

[+DrVenkman]

34 minutes ago, mytek said:

Another thing to mention that is quite annoying about Midi-Play V1.3, is the fact that it needs to fully load the MIDI file from disk into memory before playing it. A better method would be to only load just enough to get the song playing, and then continue loading the rest on the fly, providing the option to abort at any time. Since the MIDI device is on the SIO bus in an unconventional way, this concurrent operation of file loading and playing the song might not be possible via an SIO drive. However if using something like the AVG, UNO, SIDE, ect. it should be okay.

 

Yeah, that and that insufferable *CLICKING*/memory check (?) every single time, and the terrible, terrible file selector/editor when selecting files to load. 

 

Ugh. It works, but that’s about the best that can be said about it. 

[+mytek]

31 minutes ago, DrVenkman said:

Yeah, that and that insufferable *CLICKING*/memory check (?) every single time, and the terrible, terrible file selector/editor when selecting files to load. 

 

Ugh. It works, but that’s about the best that can be said about it. 

I totally agree with all your points. I guess the one thing that program does do well at is to play the file once its gone through all those gyrations

 

[rcamp48]

What about the disassembly of Midiplay? I uploaded that, has anyone been able to do anything with what I posted yesterday? Also I finally have a working copy of all of my 28 subdirectories for midi files, seems to be that small mydos files work good with Spartados 3.3b, and so far I have not seen any bad midi files, but I am still testing the output from that unless someone else wants to test them too , then I will upload the two 16 meg ATRs , granted they are all 8+3 char filenames and not the best but they do play. (I added another 6 sub-directories from 23 sub-directories and hopefully removed all of the duplicates).

 

There is a lot of new stuff that I have not uploaded here, its all on my TNSFD sever at christfollowersbbs.ca, new files are added daily.

 

Here are the two ATRs , although the title on them says blank disks they are not, in fact they are full:

 

New MIDI Files Creating System Blank Disk 1.atr

New MIDI Files Creating System Blank Disk 2.atr

 

[rcamp48]

2 hours ago, mytek said:

Another thing to mention that is quite annoying about Midi-Play V1.3, is the fact that it needs to fully load the MIDI file from disk into memory before playing it. A better method would be to only load just enough to get the song playing, and then continue loading the rest on the fly, providing the option to abort at any time. Since the MIDI device is on the SIO bus in an unconventional way, this concurrent operation of file loading and playing the song might not be possible via an SIO drive. However if using something like the AVG, UNO, SIDE, ect. it should be okay.

 

I think it is possible on an SIO drive as they put the motor control on the one I have and it comes from SIO in the first place, I do remember playing midi files from a 1050 disk drive.

[ivop]

21 minutes ago, rcamp48 said:

I do remember playing midi files from a 1050 disk drive.

Were they first loaded from disk into memory or really streamed in real time?

 

IMHO it would be pretty difficult to stream from a true SIO disk drive. You have to constantly switch clock rates and I doubt that even at divisor 0 it could keep up with the MIDI replay rate. A heavily event packed MIDI file or even just a fast song will probably not work. Streaming from IDE, yes. Over true SIO, I don't think so.

[+Stephen]

1 hour ago, rcamp48 said:

What about the disassembly of Midiplay? I uploaded that, has anyone been able to do anything with what I posted yesterday?

There's a lot of issues with that disassembly - 132 instances of ???  Even without that, and if the code would compile without errors, it would take substantially more than 24 hours to look at a few thousand lines of uncommented assembly code and make changes.

[+mytek]

2 hours ago, rcamp48 said:

What about the disassembly of Midiplay? I uploaded that, has anyone been able to do anything with what I posted yesterday?

 

38 minutes ago, Stephen said:

There's a lot of issues with that disassembly - 132 instances of ???  Even without that, and if the code would compile without errors, it would take substantially more than 24 hours to look at a few thousand lines of uncommented assembly code and make changes.

I agree. Anyone could have run that program through a disassembler. Where it gets difficult is making sense of it after the fact.

 

Besides there is so much about the program that is not good, and very little that is something to keep. Probably much better and more productive to start from scratch, so as to make it what is truly wanted and/or needed.

 

[rcamp48]

2 hours ago, ivop said:

Were they first loaded from disk into memory or really streamed in real time?

 

IMHO it would be pretty difficult to stream from a true SIO disk drive. You have to constantly switch clock rates and I doubt that even at divisor 0 it could keep up with the MIDI replay rate. A heavily event packed MIDI file or even just a fast song will probably not work. Streaming from IDE, yes. Over true SIO, I don't think so.

They were streamed in real time.... remember that my SIO2MIDI has a motor control and is SIO in the first place, I have a disk drive that needs fixing I might get it fixed and try it with my Fujinet.

 

As for the files that I sent up there are still bad files, probably SIO errors but who knows ? take a look at this video and maybe someone can tell me why certain songs bomb and certain songs do not, it is the same files every time.

 

The Atari MIDI Show Episode # 19

 

Russ

[ivop]

26 minutes ago, rcamp48 said:

They were streamed in real time....

Which software did you use?

 

Quote

remember that my SIO2MIDI has a motor control and is SIO in the first place

I don't have to remember, because SIO2MIDI is the successor of the XLD implementation, which was backported to the XEL, that was originally based on my MIDIMuse (I lobbied for that, and in the end it was simplified with an MCU), which was based on a German design in the late nineties, which was based on MIDI Mate and/or MIDI Max from the eighties.

 

TL;DR I know how this works with the motor control line

 

Loading the whole file in extended memory and then start playing is not real time streaming, so I'm very curious about which MIDI player you used that can actually stream in real time, i.e. load blocks of data on the fly from a true SIO device while already playing the MIDI file. 

 

Edited June 29, 2022 by ivop

[rcamp48]

7 minutes ago, ivop said:

Which software did you use?

 

I don't have to remember, because SIO2MIDI is the successor of the XLD implementation, which was backported to the XEL, that was originally based on my MIDIMuse (I lobbied for that, and in the end it was simplified with an MCU), which was based on a German design in the late nineties, which was based on MIDI Mate and/or MIDI Max from the eighties.

 

TL;DR I know how this works with the motor control line

 

Loading the whole file in extended memory and then start playing is not real time streaming, so I'm very curious about which MIDI player you used that can actually stream in real time, i.e. load blocks of data on the fly from a true SIO device while already playing the MIDI file. 

 

Well I pre-recorded the file with Debut from, NCH, I have a line out from my Atari that upscales from AV to HDMI and captures the HDMI from my HDMI box , I edit the file(s) as they are prerecorded then upload it to YouTube. 

 

Does that answer your question, and I use Midiplay 1.3 , load in the whole thing in my U1MB board the play it but a lot of my files are bad. (SIO errors?) I do have a loose connection in my Fujinet but it seems to work OK.

 

[ivop]

1 minute ago, rcamp48 said:

Does that answer your question, and I use Midiplay 1.3

Yes it does. It means you do not stream in real time. You load the MIDI file to extended memory first, and then you play it.

 

I have no idea why you get SIO errors. Maybe you should lower your Pokey divisor if the capacitors are still (as per stock specs) on your SIO bus?