The IFF sounds could be extended to contain the parameters used,
The programs using this sound could be lightened,
The OS could support any future expansion effects as datatypes.
 
Would it be hard, usefull, unnecessary to do it ?
 
Thank

MilkyTracker and the FastTracker 2 file format it uses support 32 voices and OctaMed SoundStudio uses 64 in mix-mode.  Hardware mixing via SIMD unit would be sufficient though.

The datatypes for AROS and AfaOS should help bring us above and beyond the OS 3.x limitations.

It shouldn't be necessary to hard-code the tracker file format into a music player.  I've written a music compiler for Protracker mods.  (Ok half written.)  It uses a coroutine in C to contain all of the musical score information which compiles to a jump-table.

Does this answer your questions?

How much workload is this to the CPU - can we quantisize this?
How much workload was this on a 7Mhz clocked 68000?
How much workload will it be on a 68K which is hundred times faster?

The most computationally intense part of a mod player is the mixing.  The playback is small by comparison.

A datatype could be built around my music compiler technology to reduce the CPU load caused by the interpreter but there is no other way to speed up the mixing than to add an SPU (or something similar) to do it for the processor.

For example an arpeggio in C-like pseudo code:

timeindex=(timeindex+1)%3;
switch (timeindex)
{
case 0:
   set_frequency(note0);
   break;
case 1:
   set_frequency(note1);
   break;
case 2:
   set_frequency(note2);
   break;
default:
   error("the impossible happened during an arpeggio command/n");
   break;
}

This is only about 16 lines of code!  It can't be done any simpler than this whether in hardware or software.

Someday I'll write another music compiler and base it on some existing code or something.  This will decrease the CPU load slightly but ultimately, this is a solution waiting for a problem.  The timers of the music scores update at the same time as the effects do so adding hardware playback functions to the Paula won't do anything useful.

The problem, Gunnar is IMHO different:
if you have a coprocessor that handles these things you can't have situations where the CPU is iverloaded and can't apply the effects wit the correct timing (and we all know timing is crucial when talking about audio).
So, a coprocessor is maybe of no use if you just evaluate the workload, but it becomes very useful when you talk about timing and parallel workload (think about copper).

But isn't this the reasons why you put a mod-player in a interrupt?
When you run a moc-player in an interrupt it will always have the correct timing - even on an 100% loaded system.

Concept is: the more overload you keep away from the main CPU the better it is. And AFAIK, that was the original philosophy of Amiga.

Don't worry.
Your fear is unbased.
The way that I described is the basis of the AMIGA multitasking.

Interrupts means that they are a priority schema.
Your audio player itself has little CPU load.
But you want that your audio player will be executed reliable at certain execution times to guarantee the smooth audio playback.
Therefore you use the interrupts to do this.
This is exactly why the AMIGA has its interrupts as they are.

Another point is coprocessors coordination. If the CPU isn't able do dispatch the requests to the audio coprocessor to let it take the job asynchronously, you'll get glitches anyway.

So there are two questions that need to be resolved. First, audio interrupts need to be served at the highest level possible. Secondly, the coprocessors must have the highest priority if they need to access to the chip and/or fast mem.

Samuel D Crow wrote:

The most computationally intense part of a mod player is the mixing.  The playback is small by comparison.

Indeed. Mixing, however, is only required if you want to play more instruments simultaneously than you have DMA channels available. The problem becomes smaller with more DMA channels available (I'm suggesting about 32 of them which should be sufficient for a while) as downmixing can be done then in hardware. The software effort for the effects are, as you say correctly, not even minimal, they are diminishingly small and no need to worry about. As said, a 6502 can do that with ease.

What might be helpful is some additional logic to autmatically reload DMA channels, i.e. include an attack-decay-sustain-release cycle somewhere in the DMA logic using separate samples for each of the cycles, and having a control register available that controls the cycle. Reloading of the Paula DMA registers was always a bit hairy and the state-chart of Paula was rarely understood correctly. The early mod-trackers used mostly an incorrect method to re-load Paula channels and hence broke on fast mem.

So long,
Thomas

Despite the performance of the memory part and may be the old OS system interrups, would there be a risk induced by a large volume of data generated by the activities of a  multi-cores CPU, the 3D core, Super AGA and expansion of audio ?