MOD Trackers or other useful music software that'll run on 286/10?

[vwestlife]

You can't use that as background music for a game or demo. Which was the whole point.

But if you wanted better music in Atari ST games, you could easily connect it to an external synthesizer, thanks to its built-in MIDI ports.

 

[Scali]

But if you wanted better music in Atari ST games, you could easily connect it to an external synthesizer, thanks to its built-in MIDI ports.

Yes, but there was no MIDI synthesizer built-in, nor was there any kind of General MIDI standardization yet (so connecting it to 'a synthesizer' isn't going to work), so that's not what you'd get with regular games and demos.
You'd mostly get horrible sounds from the YM chip, which sounded worse than some of the 8-bit machines. Nobody ever bothered to emulate YM music on other platforms for games/demos. The sound was by far the weakest point of the Atari ST.
Sierra just backported their MT-32 music from the PC version (which they were sponsored to support, I believe, making the MT-32 a sort of de-facto MIDI standard before General MIDI). Not too many people used MT-32 on a PC, because of the cost of the system, and I bet there were even less people who'd use it on the Atari.
As you can see here, pretty much all MIDI titles (and not a lot of them) were from Sierra: https://en.wikipedia.org/wiki/List_of_MT-32-compatible_computer_games#Atari_ST
And as you can also see, even the Amiga versions of some of these Sierra games have MIDI.

Funny enough, Cubase actually started on C64 (sold with a MIDI kit that plugged into the cartridge port).

 

[dr.zeissler]

One of the best experiences for SQ3 is with a combination of ST and MT-32 and SC1224.
Perfect picture and perfect sound. I recommend it over the PC-Version.
But it's a strange thing, that SQ3 on the PC has Voice-Samples that were not played
with the MT32. It's only with a Tandy TL/SL.

 

[Scali]

But it's a strange thing, that SQ3 on the PC has Voice-Samples that were not played
with the MT32. It's only with a Tandy TL/SL.

The MT-32 is not capable of playing samples.
Some games support a combination of MT-32 for music and Sound Blaster for digital effects.

 

[dr.zeissler]

Could they be uploaded as custom samples?

 

[Scali]

Could they be uploaded as custom samples?

I don't think so, I believe it only has ROM for samples.
It's LA synthesis, which means that notes are played by playing a short 'attack' sample from ROM, and then it sort of 'blends' over into 'analog' subtractive synthesis (or in some cases the short sample can be looped, which is similar to 'chiptune' mods, with short repetitive samples).

 

[bjt]

While the MT-32 doesn't have sample RAM as such, some games play MT-32 custom patches where they would play digital FX in Sound Blaster mode. X-Wing (floppy) does this in several places and I believe some Westwood games can too (Kyrandia, Lands of Lore, Dune II). Obviously while this might work for an explosion effect, it's impossible for speech.

 

[vwestlife]

The sound was by far the weakest point of the Atari ST.

It was adequate for the era and cost, and at least they improved it in the STe and Falcon, whereas the Amiga retained its original 8-bit audio until end of production, by which time it had really fallen behind the capabilities of even modestly-priced PC sound cards, as well as the game consoles the CD32 was intended to compete with.

But there's no use arguing, because both systems had their strengths and weaknesses. The Amiga's strength was graphics and professional video production (with add-ons like the Video Toaster), while the ST's strength was MIDI sequencing, widely used by professional musicians.

 

[Maverick1978]

Yes, it can do it, poorly, while eating all your CPU (because it is using the CPU to try and emulate the Amiga hardware). Heck, we've shown that even a stock IBM 5150 from 1981 can play MODs...
You can't use that as background music for a game or demo. Which was the whole point.

I call bullshit....

A mod file is just a container file that holds the samples used in the song, and then the "music" used by the composer. PLAYING the MOD file on a PC or an ST does NOT require that one emulate Amiga hardware to do so. It simply requires that one be able to decode the file format and handle it in the same manner as is required by the format.

Your argument is like saying that one must emulate an x86 processor to decompress a ZIP file on another computer. Again, bullshit. One just have to know how to handle that file format and then write the code on the desired platform to do so.

MODs appeared on the Amiga because it was basically the only computer offered at the time that gave relatively high-quality sound hardware with the cost of the computer. This wasn't something that you got with the PC, C64, or Apple II, and while it was possible with the ST, the user base wasn't there to drive the technology.

The fact is, the Amiga is designed with several custom chips that handle parallel processing tasks along with the CPU. You don't get alot of CPU usage when playing MODs on an Amiga because the specialized chips are doing the hardware processing, not the CPU, and I sincerely doubt that there's many tools (if any) that will measure this.

On the PC, the CPU does everything, essentially. Even with a sound card. So playing MODs is more intensive, and playing mod files with more than 4 channels requires a fast 386 processor.

You're arguing apples and oranges here, Scali...

 

[Scali]

A mod file is just a container file that holds the samples used in the song, and then the "music" used by the composer.

But...
1) The samples are in Amiga-specific format (Sound Blaster DACs use a different binary representation for example, they use excess-N rather than 2s complement).
2) The music data contains values that can be fed directly to the Amiga registers (as I said, things like volume and pitch are hardware-specific values).
3) The data is stored in big-endian format, where x86 uses little-endian.

Add to that that other computers of the era did not have 4 DAC channels but usually only one or two (stereo), and you had to perform software mixing as well.

All these translations mean you're essentially building an emulator.
If you call 'bullshit', I suggest you look up what the term 'emulator' means, and what it doesn't mean.
I'm not saying you need to build software that can run all Amiga hardware. I'm just saying that you need to create a 'software synthesizer' that can process Amiga-specific data, and convert it to something specific for your machine.

I'm thinking you:
1) Don't know the details of the MOD format
2) Don't know what an emulator is in the strict sense

MODs appeared on the Amiga because it was basically the only computer offered at the time that gave relatively high-quality sound hardware with the cost of the computer. This wasn't something that you got with the PC, C64, or Apple II, and while it was possible with the ST, the user base wasn't there to drive the technology.

This shows a clear lack of understanding how machine-specific MODs are.
You could apply the same argument to the C64's SID for example... "SIDs appeared on the C64 because it was basically the only computer offered at the time that gave relatively high-quality sound hardware with the cost of the computer."
Because after all, you can play SIDs on a lot of other computers as well, right?
MODs may not contain actual machine code, like SIDs do (mainly because the size/speed tradeoff for 68k code vs data is different), but they are a very low-level, machine-specific music format, very similar to SID.

The pt2play-routine is the most accurate routine around, and goes through great lengths to simulate various Paula-specific quirks to make sure it sounds like it does on a real Amiga: http://pastebin.com/pg95YduC

The fact is, the Amiga is designed with several custom chips that handle parallel processing tasks along with the CPU. You don't get alot of CPU usage when playing MODs on an Amiga because the specialized chips are doing the hardware processing, not the CPU, and I sincerely doubt that there's many tools (if any) that will measure this.

Sounds like you know nothing about the oldskool ways. Measuring CPU with tools? Pah, n00bs! We just change the background colour at strategic points in the code. Oldest trick in the book (which is why I expressed the cost in terms of scanlines in an earlier post. You just visualize and count them).
Here's an example of me doing it at an early stage of the 8088 MPH compiled sprites routine. The blue background shows the time it takes to draw the sprites (racing the beam):

You seem to think about specialized chips the way they are used today, hidden behind drivers and hardware abstraction layers. On the Amiga, you accessed the hardware directly, and a lot of the data in the MOD file is fed directly to the chips.

 

[KC9UDX]

It was adequate for the era and cost, and at least they improved it in the STe and Falcon, whereas the Amiga retained its original 8-bit audio until end of production, by which time it had really fallen behind the capabilities of even modestly-priced PC sound cards, as well as the game consoles the CD32 was intended to compete with.

It wasn't really a problem. Technically, Amigas typically use 14-bit audio.

I think Commodore had an official solution involving the MC56000. But we all know what happened there.

There were some really nice sound cards for the Amiga, but they weren't popular because the inbuilt audio was good enough.

My biggest gripe was the lack of audio input. But there too, there were plenty of aftermarket solutions.

 

[Scali]

It was adequate for the era and cost

Well, I strongly disagree with that.
The ST sounds horrible for a 16-bit machine. It doesn't even sound as good as a C64 in my opinion.
There's a reason for this: the engineers at Atari wanted to develop their own sound chip. But because Tramiel insisted that the ST be on the market before the Amiga, they had to scrap their own design, because it wouldn't be ready in time, and used an off-the-shelf chip instead.

But there's no use arguing, because both systems had their strengths and weaknesses. The Amiga's strength was graphics and professional video production (with add-ons like the Video Toaster), while the ST's strength was MIDI sequencing, widely used by professional musicians.

Owning an Atari 1040STe for Cubase use only, and Amiga for everything else, my view is that if the Atari ST didn't have MIDI, it would have been a complete failure.
The Amiga was better at everything, and would also have been a great MIDI sequencer. It's just that MIDI didn't come standard, so people went for the out-of-the-box MIDI with Atari. I think Atari lucked out there, they most probably didn't foresee it taking off with Cubase.

 

[KC9UDX]

I bought an ST to run Cubase. I ended up running Bars&Pipes on an Amiga instead.

I had the ST for probably 15 years and the first time I got round to powering it up, I took pictures and sold it, very quickly. So I never got to experience Cubase on the ST.

But, Amiga does MIDI pretty well.

 

[Trixter]

This shows a clear lack of understanding how machine-specific MODs are.

They're not that machine-specific. MODs don't contain machine-specific code. Signed samples are not an Amiga discovery, nor are big-endian integers. In fact, only the use of the Amiga period table is Amiga-specific. (No need to mention the Filter toggle, there are less than ten modules that actually use it.)

You expressed surprise in a previous post that MODs were successful outside of the Amiga; doesn't their success outside of the Amiga prove they couldn't have been all that machine-specific?

This conversation is starting to piss me off. You don't have to talk down to people just because they had different experiences than you did.

 

[Scali]

They're not that machine-specific.

Yes they are.
If they weren't machine-specific, they would use note frequencies or indices or such, rather than Paula DMA periods, for example.
There are other, smaller details, that you may not even be aware of, such as sample positions (for loops etc) always being an even number.

Signed samples are not an Amiga discovery, nor are big-endian integers.

I didn't say they were. I just said they were native to the Amiga. Had a MOD-ish format been designed for a different platform, or for multi-platform, then different choices would have been made (some PC trackers use excess-N samples, and different note data etc). But no, the design choices are Amiga-specific.

You expressed surprise in a previous post that MODs were successful outside of the Amiga; doesn't their success outside of the Amiga prove they couldn't have been all that machine-specific?

No, that is a fallacy.
The fact that something is implemented on other platforms doesn't say anything about how difficult or inefficient this is.
That's like saying the Amiga hardware couldn't be all that special, because you can emulate it on many other systems with UAE.

This conversation is starting to piss me off. You don't have to talk down to people just because they had different experiences than you did.

The conversation is pissing me off as well. I take offense at someone saying "I call bullshit" to things I write. I wasn't the one who started talking down people. I just thought that guy should be put in his place. It's obvious he doesn't know what he's talking about anyway.
I have written plenty of Amiga code over the years, including playing around with ProTracker routines. One of the first audio projects I did on PC in the 90s was also a MOD player.
I'm just trying to share my knowledge and experience on the subject, and I don't liked being talked down to and my posts being called 'bullshit'. It's not. I'm telling it like it is, no more, no less. I know what I'm talking about.

Let me spell it out one last time for the completely clueless:
My point is that when the MOD format was designed, compromises were made to make it compact and efficient on Amiga hardware.
If MOD was a 'generic' format, where the primary goal was to get the best possible music quality, different choices would have been made, to allow for higher quality instruments, better effects etc.
There are various other music programs on Amiga that try different things, such as AHX and OctaMED. These are not popular for games and demos however, because of the CPU load.

 

[Maverick1978]

While not a programmer, I've been an in-depth power user over many platforms, including the Amiga, since grade school. That's pushing nearly 30 years. A bit younger than you, perhaps That said, I'm very familiar with how the Amiga's work, how they address their custom chips, and also the term emulator, both in the modern sense and the classic sense. You specifically referenced that mod players emulated Amiga hardware. In the modern use of the word emulator, with "modern" being the accepted definition in use since the mid-late 90's when emulation programs first started appearing - coincidentally about the same time the MOD format came into being and then appearing on PC platforms soon after - hardware is implemented in real-time via software and typically requires a fast computer in order for the software running on the emulator to be utilized at "normal" speed. In that sense, which is how pretty much ANY user these days (or 20 years ago) would take for the definition of the word "emulator" being used in the context for which you used it - then no, a trakker program on a PC or other computer is not emulating an Amiga computer or any of its hardware in any way, shape, or form.

IE I called bullshit. Perhaps not the most forum-friendly way to have done so. My apologies for that.

If you're using the term "emulator" in the loosest sense, where an "emulator" is anything that attempts to perform an action that something else normally does - such as making concessions for any compromises in the design of the container format that is a MOD file - then perhaps... from a left-field point of view... one could consider a trakker program on a PC to be an emulator of Amiga hardware. In the same way that a 8088 PC emulates an Apple II. Or a Commodore 64 emulates an Apple. Because they all perform tasks based upon user input. Copying the actions initially performed on another device.

This does NOT mean that a PC emulates a C64's hardware, or that C64 emulates an Apple's hardware, etc. Not by any stretch of the imagination.

Don't get all uppity because you incorrectly stated that trakker programs eat cpu cycles "to try and emulate the Amiga hardware" - that's just incorrect information, and defending it from a bully pulpit isn't going to make the statement any more correct.

With that said... I will agree wholeheartedly with your spelling things out for the completely clueless - which, I'm assuming, meant me, however incorrect that is But I'll take that one on the chin since I started the poop slinging with my bullshit comment THAT statement is 100% correct. If you'd said that from the get-go instead of defending your "emulate Amiga hardware" statement, you wouldn't have had me calling bullshit, or Trixter calling you out from a much more informed point than I am, since he's obviously a highly talented programmer that's been in the game since those early days.

 

[cthulhu]

On a mostly unrelated note, did you know the ECS and AGA Amigas can do up to 56 kHz audio DMA in certain screenmodes?

 

[Scali]

On a mostly unrelated note, did you know the ECS and AGA Amigas can do up to 56 kHz audio DMA in certain screenmodes?

Yea, that's what I said earlier, if you use the CPU to write to the sound chip directly, rather than using DMA.
I believe AGA machines can go even higher than 56 KHz.

 

[cthulhu]

Yea, that's what I said earlier, if you use the CPU to write to the sound chip directly, rather than using DMA.
I believe AGA machines can go even higher than 56 KHz.

But I'm not talking about using the CPU. Reread what I wrote.

 

[Scali]

In the modern use of the word emulator, with "modern" being the accepted definition in use since the mid-late 90's when emulation programs first started appearing - coincidentally about the same time the MOD format came into being and then appearing on PC platforms soon after - hardware is implemented in real-time via software and typically requires a fast computer in order for the software running on the emulator to be utilized at "normal" speed.

This is not correct.
Have you ever heard of JIT-compilers? These are sometimes applied in emulation. For example, WinUAE has a JIT-compiler, and VirtualPC for the PowerPC Apples did as well.
Or the x86 Windows-on-Windows layer for DEC Alpha for example.
Java and .NET apply the same concept, except they 'emulate' a virtual CPU, not a physical one.
DirectX shaders on GPUs also work this way: they are compiled to bytecode for a virtual GPU, and when they are being applied to an actual rendering operation, the driver will compile the bytecode to native GPU code.

These JIT-compilers compile a piece of code 'just in time', which generally means the first time it is called. Once the code is compiled, the native code is cached, and subsequent calls to that same code will be redirected to the cached native code directly.
In some cases, the performance of this recompiled code is actually higher than that of the original system.

And this is very similar to MODs. On Amiga they are played as-is. On other systems, a lot of data needs to be translated. This may be done when the MOD is first loaded, rather than during actual playback, but that is just similar to the JIT-style of emulating a processor.
Software mixing is similar to how emulators interpret instructions one-at-a-time in a state-machine.
The software mixing buffer is a bit of state that only exists to emulate how an Amiga works, and is not something that is physically present on the real thing. It is part of the translation/emulation you're doing.

Don't get all uppity because you incorrectly stated that trakker programs eat cpu cycles "to try and emulate the Amiga hardware" - that's just incorrect information, and defending it from a bully pulpit isn't going to make the statement any more correct.

Even if you don't want to accept the term 'emulation', it doesn't change the fact that MODs played on most platforms eat a lot more CPU cycles than on Amiga, because they have to do software mixing.

Trixter calling you out from a much more informed point than I am, since he's obviously a highly talented programmer that's been in the game since those early days.

Yes, Trixter has been in it for about as long as I have, perhaps even longer. But he's looking at it from the PC side, where I come from C64 and Amiga.