Scali!
Well, I could do the hardware. I could learn about the tracker software, as I have 100 hours time for the soundcard project every week, but I am not sure if I ever can do the software side to such level that it begins to work before 10 years will pass, becouse my fiddling can take hours, what is for a real coders just 5 minutes work... or if I ever find a place in a Impulse tracker software where to put the extra MIDI output support. At the same time there could be a new version of hardware.
unfortunate, but here it is-- I can just somehow turbo pascal, C, assembly (from 286 to Pentium MMX) in which I have done programs, also I have also optimized the source functions in C and Pascal, and Delphi 6.0 in a assembly language (it was couple functions which I optimized, in a program consisting of 100 000 lines, while I did not knew the rest!). But thats all. Small programs, assembly language, optimizing, and such. In university and on every other additional course we heard how important is the documentation, while real world (most of the corporations) virtually never use it, in which I have seen, also zillion other big programs in the internet.
Unfortunate, but in big source codes (well >10 000 lines) I am lost, becouse unfortunately all the creators of the big programs think that there is never need to document properly everything. SO , but I cant do nothing without proper documentation which should be with similar thickness as source code itself, and the flow diagrams, the variables used and for which occasion and how they change (hey, should EVERYONE really figure out all the magic variables?). THe only thing I can do in a huge, big programs, there is to compile, if all is clear with red-and-wooden example.
Hey, simple VGA routines, there are detailed instructions and explanations WHY it has to be done so, now imagine the same tutorial for the program which source code text is already 2MB Turbo Pascal code! There is not in these cases detailed manual.
Usually there is none in the 99% cases what I have seen about program developments... all this information which is needed to write down is still in the authors Big Fathers head only and all this documentation spreads by word of mouth way. Well I just cant explain it simpler. Then the thought is "hey, where to put this or that routine when to add a new function? if I modify this function which one uses this really? and why THIS is modified? or... to find the bug!").
STILL, (as I said before ) if I just get the more detailed explanation about the program "bottle necks" becouse of programming then it can give
also a clues how the hardware (soundcard) can be adapted best to make software better and efficient.
For example: just after reading the entire SB development kit, there are many with all those assembly examples which are routines for communications, it gave a several ideas how actually the protocol could be simplified to reduce the bus and CPU overhead -- by just adding a little bit more extra hardware for soundcard side.
JUst getting a slight idea about how the software is, should avoid these situations like "for this function it would be much simpler in assembly routine ONLY IF the hardware would be done that xxxxyyzz way instead, but now it causes more CPU and bus overhead"
The thing could be different if there would be some simpler examples of the trackers -- so WHERE TO BEGIN FROM! JUst a long 669 tracker file, without sufficient level explanations were really not something which I would understood even 20 years ago. ;( However things like Turbo Pascal, TUrbo assembler alike tools are my favourite, so no problem with the interface (becouse I despize windozas) . I almost dreamed about such a job like that in the past with just exactly THESE tools -- programmer under the DOS.
Why FT2 was not developed for support with a thought for 2 soundcards? There were already quite a time ago games which supported 2 soundcards (one for music, second for FX and such) ). With a trackers which had support for 2 soundcards, it would be 2 MIDI ports, and 4 audio output channels already.
The all I could program can be just a multitrack soundplayer/soundrecorder example later for my new card, but thats all I am capable of (just now atleast).
So, just now I see just this way that well, trying to look these sources. If this does not help then those who are capable of programming will get the card who hopefully write trackers support for these cards too.