My last tracker thing took over a year to make and I worked on it every day pretty much while also getting paid to do it, it is a huge amount of work. None of the existing tools appeared overnight, all of them have a tremendous amount of work behind them.
Since such stuff hasn't appeared it likely won't, if you need some you'll have to start making the first step and perhaps someone will come along and help. My hands are full already.

Yes, big undertaking I know.

Let me rephrase:

My question is more about ideology --- what happens in their heads who take this huge step to make their new tracker programs (and also FT2 remake), BUT their requirement is the latest M$ platform and for the last hardware only? Despite the fact that it imitates old tracker version!

There would be no reason to avoid DOS longer

There are those who say "the dos is dead, there is no support and no new hardware", but none of these points are valid -- here we have already 3 remake cards to hold in a hand, we use it very vividly... and yet all the software is old ones.

Maybe it makes more sense to start off with an existing open source project and expand it. E.g. Impulse Tracker is available:

https://bitbucket.org/jthlim/impulsetracker

If you are talking more about OPL2/OPL3, other FM cards or Tiido's YMF card, I am not sure there is something available to use as a starting point.

On the other hand, a rather small scale project might be doable, like the three channel tracker that is being developed for Planet X3. Here they only support a few cards. Keeping the features to a bare minimum might be a workable path. Do not start to take on too much at once.

root42 wrote:

If you are talking more about OPL2/OPL3, other FM cards or Tiido's YMF card, I am not sure there is something available to use as a starting point.

AdlibTracker II is a good starting point there:
http://adlibtracker.net/

root42 wrote:

If you are talking more about OPL2/OPL3, other FM cards or Tiido's YMF card, I am not sure there is something available to use as a starting point.

For OPL2/OPL3 there is Adlib Tracker II with source available.

My thoughts are about tracker with emphasis for multiple MIDI in/out ports and multi waveout ports (just like FT2 but with multiple card support and routing). Just look -- the FT2 can be used as the whole MIDI sequencer to both record in and also send out MIDI on all 16 channels. So, I thought about something like that, but with multiple audio outputs and MIDI output ports when having multiple card or just as I said... designing new multi-MIDI port card.

Well, I am very okay with that if my work is on emphasis for the card and other dudes do the software . But I cant do both.
Thus, I begin with the card.

Soon I post the plans about the card too.
ALso there will be plans soon after I have plans ready for start. It is still in the plans about the decisions what to use and how.
Also the first steps will be in a way that everyone with a breadboard can follow and copy it spontaneusly, thus some development can begin in parallel.

I'll let Steve Ballmer do the talking: https://www.youtube.com/watch?v=Vhh_GeBPOhs

This Forum is mostly about collectors, archivers, people documenting, gamers, nostalgists and some hardware devs. Very little software developers around and if they are, they're usually tied up in a bunch of projects already or consider demomaking more interesting (which I can't disagree with).
Being the "main" guy behind the ARGUS, I was extremely lucky to have 640K!Enough and wbc!bz7 join my efforts and supporting me on the software side (except for some BASIC coding I absolutely dislike programming and usually avoid it). I know of another effort, which I was told not to publically mention til it's out - but that one has the issue of the dev having little time as well.

Considering we got a SID player for the SSI 2001, alternative banks for the ARGUS in the making along with 2 working memory dumpers and some popular stuff like softMPU and patched programs for the LPT2xxx projects by serdaco I think we're kinda lucky - I know other platforms which get more hardware development, but actually _no_ software updates whatsoever.

DEMOMAKERS.. YES!... But they are also doing the both games, demos, and all such stuff for old hardware too.

I thought it would be better to get a word outta there -- we need developers. Demoscene, music magazines, and...more something?

The one thought is demoscene, since now they are STILL doing the demos for a C64 and also for Pentium 133Mhz machines and such, (it reminds me the event that how demoscene took into their heart the Gravis Ultrasound becouse Soundblaster development kit was not free). On old days demoscene programmers were dependant on the hardware manufacturers, but NOW, halloo we make our own cards and thus we are in direct contact!

And also several music magazines... I think or believe that people are still interested about this, but they just do not know what is happening in the corners of the internet (just a year ago before I discovered ARGUS thread, I thought I was the only dinosaur doing ISA bus stuff!).

IF just to begin this way to give a light that how many retro card clone projects are here already then it is very good one, and also if just to have all the hardware documentation open or easy to copy then it will inspire others to make or develop too. (well I still try hard to limit the stuff to the discrete elements stuff for my soundcard projects).
It still needs planning careful way, otherwise it will be running to wrong direction.

Also those who can barely solder, also can start developing some hardware too if everything is not about 0603 SMD components or 240pin FPGA chips. It is really normal thing to do. I guess?

So, why not just to present all this with our ready made cards on the demoscene events... well, gravis ultrasound comeback, but also we can now do entirely new standards of our own which were too expensive back then (to imagine several soundcards in a machine for example, or to do it yourself!).(Just now I feel high and excited about this idea -- new card makers at the ASSEMBLY event). The thing is that it gives a real boost to RETRO DEMOSCENE.

shock__ wrote:

Being the "main" guy behind the ARGUS, I was extremely lucky to have 640K!Enough and wbc!bz7 join my efforts and supporting me on the software side

Yes it is incredibly lucky.
well, I remember and I am STILL admiring all that process how Your ARGUS process began. To me it is the first forum where I see a co-laboration and co-op both in electronics and software wise. 😀

To me unfortunately the software side is bad too. I am stuck if it will be more than just couple TPU files to compile in turbo pascal or C or if there is need to debug a strangers programs in their spaghetti code.
It seems to me bery odd or unlucky that -- 1. compilating and linking big programs are first obstacle. 2. missing documentation is the biggest obstacle. Yet I heard in school that the documentation is very very important.
Yet how come every time I see a long program, there is no documentation ? Also no information about how to set up compiler and to compile it right (this is rare if there is such info!) and always there is a mess about compilers at first before I ever can reach to debuging. And then there is no description of the whole flowcharts of operation.

At the same time there are such programmers who can understand others spaghetti code, they develop program real fast, yet to my surprise sometimes they say very odd things -- that they hate soldering, are illiterate in electronics and so on. It is very usual to hear that they cant solder not even cables.
So, thats why I came to conclusion that its better that the coders do the programming since they do in 5 minutes what I do in one hour (or in one day) in the huge programs in my eyes. ... and so, we do the cards?
It is enough if I just do the CPU firmware only or some assembly tweaks and other small programs, but I feel hopeless in huge programs which have NO documentation whatshowever and have 20000...100 000 lines (assumed it is C, Pascal, or Delphi).

To me in electronics inside synthesizers it is the exact opposite : there are the schematics, and there is relatively little effort to read the schematic - it is almost relaxing.

shock__ wrote:

I'll let Steve Ballmer do the talking: https://www.youtube.com/watch?v=Vhh_GeBPOhs

This Forum is mostly about collectors, archivers, people documenting, gamers, nostalgists and some hardware devs. Very little software developers around and if they are, they're usually tied up in a bunch of projects already

... mostly emulator developers and wrapper authors... 😁

IMHO. Just start project, show something. If people will find it interesting they join. This is group of free people, "hotheads" who wants to share their knowledge and show their achievements.

I have a feeling that you want to be project manager. You say "our, we, us", but want the others to do something. It does not work this way. Of course you may bring several ideas, but you shouldn't expect people to realize them. Of course it _CAN_ take place.

No offence.

no offence taken.

zyga64 wrote:

IMHO. Just start project, show something. If people will find it interesting they join.
...

Some schematics now, yes!
and of course I said "We" becouse it is not meant to be solo project .

well, the things can take a while when you all see some printed circuit boards populated. But...
It needs input with electronics, software, firmware, or in other areas becouse I am not very bright with all areas at the same time.

AND the things with some development do begin actually with the component choice and planning for this so there will be no running to wrong direction or ordering enthusiastically wrong components .
However so far there has not been not enough input even about those very very basic questions like the need for FIFO buffers in which actually I was totally alone, however of course absolutely everyone knew the specifications by heart that CS4231 has 16 byte fifo buffers! Right?!
Can be that I was lucky enough with the "very basic" question about 17.5mks related to DMA transfer transaction. But of course the conversion from big endian to little endian numbers, signed-unsigned number conversion in hardware ... but all also
in a way that to do it without FPGA. (in one reason it is too early to me, as I just got into this area, for second then it will be much simpler PCB for others who cant solder 240-pin chips).

It will be complicated. to me. But with one thing I am pretty sure - a some eccentric thought -
Those who just want to get this with money only, can as well forget it -- It is NOT going to be so that I do it alone 3 years , and then those who want the card too, will just give $$$$$ or £££££ and call it a day.
MOney is not helping there, becouse even with sales from 1000000 cards there will be not possible to buy something in return which is in my interest, becouse these things do not exist and must be made at first.

zyga64 wrote:

IMHO. Just start project, show something. If people will find it interesting they join. This is group of free people, "hotheads" who wants to share their knowledge and show their achievements.

updated, the schematics about the plans published. see the thread yourself. It has been 5 weeks work so far with its research and development. As I dont really know the appropriate software for making such diagrams (not for the usable platforms), I prefer all this manually.

An alternative for developing new trackers is to make processing tools that take existing music files as input, and prepare it for custom replay routines.
MIDI or MOD/XM files are good formats to start from. It saves the trouble of making an entire editor, so you can concentrate only on getting the data to the card in the best way possible.

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.

root42 wrote:

Maybe it makes more sense to start off with an existing open source project and expand it. E.g. Impulse Tracker is available:

https://bitbucket.org/jthlim/impulsetracker

THank You, but WHO would be that capable of modifying that? I looked the source. There is no documentation about the program source. I even dont know the data flow about this.

Scali wrote:

AdlibTracker II is a good starting point there:
http://adlibtracker.net/

to WHOM is the starting point? ' Thing is so, that AdlibTracker source has nowhere any documentation about source in that repository. 100..300kB long source files and there is not a sincle comment line in 1000+ line neighbourhood or in the functions about clarification.
I could as well just to read the disassembler source and be just a little bit less aware about the program. 😉

To me it needs to be quite tiny steps.
The starting point to me would be when someone starts making a tracker and every time creates a daily log what has been changed and not more than 10kB source at once. ("Just keeping it real" about trackers. But it will be 100 episodes perhaps?).

Yes, if these can be starting points for you dudes, but certainly not for me. For THIS source I need the documentation which would be also the same thick as the source to atleast get SOME overview about how it is built.

I think I will succeed to teach for some programmers how they can build from the scratch the EPROM programmers before I reach so far to add even some major meaningful line in these huge programs.

Well, I personally found the Adlib Tracker II source code to be quite poorly written and hard to maintain/improve as well.
But I used it to generate DRO files from DOSBox, and then I made my own replayer for OPL3 for it. This player needed a lot less memory and CPU resources than Adlib Tracker II, so now it could even run on an 8088.
I used it in the Outline 2018 invitro: http://www.pouet.net/prod.php?which=75755

And for the end-tune in 8088 MPH, reenigne made a tool that took a ProTracker MOD as input, and generated a custom file from it as well, optimized for his custom player.

I think various hobby projects can use similar approaches.

Well, I personally found the Adlib Tracker II source code to be quite poorly written and hard to maintain/improve as well.

Scali, I could not even understand atleast this if it was well or bad written. 😉 To me it was impossible to understand and maintainable only for the original author of that software package.

well, hang on, it smells like you are into demoscene and not just slightly. 😁 I am very fond of demoscene.

Soon when there will be some card, I hope you are still enthusiastic to play with some hardware to develop. Software I mean. Also in hardware further development in the progress I want to know at the side some details about the program so I could adapt the hardware to make it more easible i programs and for CPU.

https://bitbucket.org/jthlim/impulsetracker

http://adlibtracker.net/

Those mentioned sources about trackers are absolutely useless.
In some more sophisticated companies those dudes get fired right away who write code this way and then add into some repository this way new features.

I heard at least this -- spending more time than 35% to write a code in the program development is a waste of time. (and we know what must be the rest of the 65%).

It does not apply to individual/solo programming projects and very trivial hello-world ones, but clearly not in those huge codes which should be passed on or teamwork. They think that documentation is just comments, and forgetting the block diagrams in the higher level.

One weird thought after reading these here:
https://www.artima.com/weblogs/viewpost.jsp?thread=4183
http://misko.hevery.com/2008/08/17/singletons … ological-liars/
(which I recognize very well as being in these situations several times as a newcomer in a company).

Lets say, hypothetically -- I could pay for programmers even 3000EUR per month for next 2 years who could make trackers in order to just get my dream program, but those who are eager to start (there is a site for hiring a coders) then they do just spaghetty code, there is no plans, have no sense what is needed to comment and what is not, dataflow diagrams, so it ends up being "write only" and buggy as hell as the time moves on with developments and program complexity increases. Thats not the deal since the poorly documented code is too much common practice.

https://blog.codinghorror.com/avoiding-undocumentation/
And I second that...
😉 very clear.