Hardsynth Tracker

[analmux]

I'm still interested in writing a new pokey tracker, making use of all the presently known pokey features. Pulsewidth reset/offset, polycounter reset/offset, 2-tone-filter.

 

I already did some years of thinking, and a tracker/player is already there 'in theory'. But, I'm still wondering whether I should write a user-friendly tool, or just one for private usage.

 

To make clear: I don't promise anything, so don't expect any tracker from my hand. But, I'm considering to write one now.

 

Thinking about making a user-friendly tool: Supporting midi-import would be a nice feature. One of the first features to work on.

 

A question about the midi format: As far as I know, the midi-format is not that difficult, but possibly there's some issues with it. At least, that's what I'm afraid of. Some midi files make use of extended commands, and the midi2pokey converter should not have a hang-up or other issues, as it got an unexpected command. So, could anyone confirm (or deny) my assumption that the midi format has no weird or weary surprises?

 

I'm not sure whether I would support .mod import or .sid import.

 

I have another question about features: Which features do you think are important to include.

 

For example, me myself thinks that it's nice to have a free number of user-defined notation tables, but also some basic ones. These tables will be included in the project file itself, but not in the final binary to be exported. One possible issue could be arpeggio or pitch bend effects...

 

 

Another thing: Should the tracker itself be a PC-tool or not? Many of the newer features only work properly on the real thing. At least filter/pulsewidth offset and evolution, but also polycounter offset give different effects in emulation, compared to the real machine. So, a partial solution could be that we indeed use a PC-tool, but also a nice fine-tuning tool to run on the real machine. Another solution would of course be an atari-native tool. It will only work on the real machine. But, the disadvantage might be the user-friendlyness. On PC we do have a lot more workspace.

 

 

Any other ideas?

 

Etc.

 

Thanks for your time.

[Rybags]

I'm not a music type guy so bear with me...

 

A "virtual voices" type of system would be good. To that end, also have "priorities" where one type of note or effect will take precedence over another.

Another nice feature but possibly hard to implement - dynamically remap those virtual voices to physical ones on single or dual Pokey.

 

Something like that would make doing game sound effects integrated into the tracker somewhat easier. You could decide whether you wanted certain effects to take precedence, e.g. you might let shooting effects take precedence over drumbeat of the music.

 

Of course another thing to consider is digitised sound.

 

Yet another might be ahead-of-time processing of music and maintaining a buffer. So, for example if you have a particularly bad frame where you have barely any CPU time, you've got a buffer of notes that you can just do a quick lookup of, then when the load dies off a bit, you can do multiple tracker calls to build the buffer up again.

[Heaven/TQA]

I am not musician, too... so I as programmer would like to have simple "Export functions" in the tracker. And I have to admit would not prefer "native A8" tracker simply because of all the cross development tools.

 

And as Rybags mentioned... a gaming friendly replay source code... and yes, digi support would be great, too.

[ANTIQ]

A hardsynth / sample hybrid thing might permit higher sample frequencies.

 

I always thought the Namco WSG approach was a bit neglected...

[DamageX]

A "virtual voices" type of system would be good. To that end, also have "priorities" where one type of note or effect will take precedence over another.

Another nice feature but possibly hard to implement - dynamically remap those virtual voices to physical ones on single or dual Pokey.

I think that will be necessary because midi files permit overlapping notes on one "channel." So even if there only four voices in a midi file you can`t always map them 1:1 with POKEY channels.

[emkay]

The "hardest" with hardsynth is to find a way for using the replay routines VBI independent.

The generators have to be programmed, like handling samples, just with less updates per second.

 

Particular Project - M would benefit much of it.

 

 

 

 

[analmux]

A hardsynth / sample hybrid thing might permit higher sample frequencies....

I'm not sure what you mean with this sentence. Could you please elaborate a bit more? Do you mean 'higher' sample freqs than f.e. another sample engine? Or...

[analmux]

...Another nice feature but possibly hard to implement - dynamically remap those virtual voices to physical ones on single or dual Pokey...

Might be a very nice feature. I did some thinking about a similar feature some year ago.

 

When the tracker is a PC-tool, you could in theory work with a 16-track virtual tracker. Then work with priority values and fill up the 4 available real tracks/voices.

 

The problem is, I have no real experience in coding a PC-tool. Only some simple .atr editing tool to include binaries from DOS and integrate them in an .atr image, but there already exists a similar tool which is far better.

 

So, I think a PC-tool for editing tracks will be great, but I'm not sure how to do it, and which script language to use. Possibly any suggestions? For example, which programming environment is used for RMT?

[miker]

Well - it may be related to what Rybags say (but it was present also in some brainstorm on some parties).

 

So - what about making the sounds like sawtooth/triangle/other nonstardard ones as hardcoded (with user-defined envelope), and let the program decide which voices should be used for current instrument.

 

It may sound strange but it may also bring some new musicians into Atari scene.

[Marius]

For me is the most important it runs on Native atari 8bit.

 

The fun part (for me) is using the REAL equipment. The fun is the coding/creating ... when the job is done (the program/music is ready) the biggest fun is over -for me!-

 

I like to spend time with the Atari. Not spending time with mac/PC.

 

I really appreciate what all crosscompiler-users create on Atari 8bit. And I must say: they get much more done, than I ever will. But I don't understand the 'fun' so much.

 

I'm still using Chaos Music Composer and Mac/65 and a lot of other native Atari 8bit tools. Like SuperPacker, diskrx and a font-editor. All this combined with Qmeg and Blackbox, gives me a very nice set of tools, and the chance to spend hours with my beloved Atari 8bit.

 

So for me: a powerful native Atari 8bit music tool, would be VERY appreciated.

 

Thanks

Marius

[Creature XL]

For me is the most important it runs on Native atari 8bit.

 

The fun part (for me) is using the REAL equipment. The fun is the coding/creating ... when the job is done (the program/music is ready) the biggest fun is over -for me!-

 

I like to spend time with the Atari. Not spending time with mac/PC.

 

I really appreciate what all crosscompiler-users create on Atari 8bit. And I must say: they get much more done, than I ever will. But I don't understand the 'fun' so much.

 

I'm still using Chaos Music Composer and Mac/65 and a lot of other native Atari 8bit tools. Like SuperPacker, diskrx and a font-editor. All this combined with Qmeg and Blackbox, gives me a very nice set of tools, and the chance to spend hours with my beloved Atari 8bit.

 

So for me: a powerful native Atari 8bit music tool, would be VERY appreciated.

 

Thanks

Marius

 

Oh boy. I just discovered the debugger of Altirra. If nothing else that would be a reason to use PC-tools.

I coded years on the XL with Thorsten Karwoths assembler and 256k of RAM. Was nice, but when you got a nasty bug the system freezes and you had to reboot.

Using my PC (with Linux) and atari800 makes life so much easier. I use CC65's assembler (ca65) which has very nice features combined with GVIM its fantastic.

I wrote a blog article about using ca65 but it is not published yet

 

 

@musictool:

Please do it! And be sure to talk often to emkay. Would be nice if he finally is content, because I think he can make nice sounds with a proper tool.

If you make a PC tool for Windows, you can use C# (or VB) and make a Windows-Forms-App. Its pretty easy. I am more a Linux guy (GTK, QT) I think C# would be easier

Well, and there is JAVA. that would maybe be the best as everybody can run it on his/her PC. But you need POKEY-emulation for JAVA then.

Concerning the sound quality on real hardware. Its simple enough with SIO2PC cable to load a file from the PC. So it might be possible to make a player for the 8bit (you need that anyhow) and load a WIP track over SIO2PC for a test. If it sounds like you want you can complete the compose process on the PC.

OTOH you can consider to make a sound-designer-only proggy for the A8 and then save the sounds over SIO2PC to the PC and use the sounds with the tracker.

 

 

Is there absolute no possibility to get the source from the RMT author and make a spin-off? considering how much work he has already put into it what you will have to recode.

[ANTIQ]

A hardsynth / sample hybrid thing might permit higher sample frequencies....

I'm not sure what you mean with this sentence. Could you please elaborate a bit more? Do you mean 'higher' sample freqs than f.e. another sample engine? Or...

 

It's nothing very clever, I was just wondering if playing 2x16-bit hardware waves and 2 samples of frequency 2f would sound nicer than 4 samples of frequency f, say.

[ANTIQ]

It would be cool to hear a "fast enough" CPU driving a POKEY.

[emkay]

You remember this one?

 

Slow.zip

 

 

Beside the straight programming of "Hardsynth", and digitizing, we have the possiblility to build interferences on the generators, to create the "3rd" type of sounds.

This tune is based on real 4 channels and uses a fixed VBI speed. Now imagine, you could do various update speeds.

 

So, we'd have 3 fully different types of pokey programming yet. The perfect tracker should be able to use all of them.

 

Imagine:

 

One straight programmed "Hardsynth"-Channel , either using simple filter and/or Modulations..

2 channels build sounds with variable updates.

1 channel is build upon digitizing.

Or, someone may use 2 16 bit channels with variable updates, plus a digi channel....

 

Or do combinations of all possible in one tune

[Marius]

@creatureXL

 

Ofcourse PC-tools are fabulous, but it is beside the point I tried to make. I like to USE my Atari as much as possible. So when I am going to write 6502 code, or when I compose/arrange a song for Atari 8bit, I simply USE my Atari 8bit. That is part of the fun. And using the Atari = 100% fun. When I had to make money writing software for Atari, it would be perhaps a different story.

 

I'm sure several Atari related PC tools are incredible.

 

And the 130XE+ assembler of Torsten K. is nice, but there are (much) better Assemblers for little atari. I've used the 130XE+ assembler about 2 years, but then I returned to Mac/65.

 

And another point of all those PC related tools. I'm using a Mac.... and since my iMac G5 is not able to run these tools in Windows, I have another reason for wanting them for atari 8bit.

 

But it's ok, the author decides. When I'm done with CMC, I will try MPT or TMC. I have enough options left.

[analmux]

Thanks to all for replies.

 

Here's a first concept scheme of the hardsynth environment:

 

 

Edited January 2, 2011 by analmux

[Heaven/TQA]

@creatureXL

 

Ofcourse PC-tools are fabulous, but it is beside the point I tried to make. I like to USE my Atari as much as possible. So when I am going to write 6502 code, or when I compose/arrange a song for Atari 8bit, I simply USE my Atari 8bit. That is part of the fun. And using the Atari = 100% fun. When I had to make money writing software for Atari, it would be perhaps a different story.

 

I'm sure several Atari related PC tools are incredible.

 

And the 130XE+ assembler of Torsten K. is nice, but there are (much) better Assemblers for little atari. I've used the 130XE+ assembler about 2 years, but then I returned to Mac/65.

 

And another point of all those PC related tools. I'm using a Mac.... and since my iMac G5 is not able to run these tools in Windows, I have another reason for wanting them for atari 8bit.

 

But it's ok, the author decides. When I'm done with CMC, I will try MPT or TMC. I have enough options left.

 

You could run Eclipse + WUSDN IDE + Mac port (intel or PPC) of MADS. so nothing to stop here...

[analmux]

...some more comments:

 

About the high-level tool (MIDI import):

• In this scheme, this tool will only import stripped/basic/standard MIDI format files.

• I'm not sure how to code such a tool and how to access pokey.dll

 

About the mid-level tool (Hardsynth Tracker):

• I prefer an atari-native tool for this level

• I'm not sure whether I'd add digi support, but an external command channel could be an intermediate solution (then add an external digi player)

 

About the low-level tool (Hardsynth Player):

• This should be a library, not really a "stand-alone" executable

• The update speed could be 1,2,3 or 4 times a frame (PAL 50 Hz / NTSC 60 Hz), but in theory also another arbitrary value

• The very important thing which I called "executing time" means the exact timing when the pokey-reg updates will take place, thus means the rasterline # of each call. The executing time is meant to be controlled by the song writer himself. Controlling pulsewidth modulations depends on this timing.

• Notation tables will be thrown away after export to binary, just because otherwise a song with many advanced instruments will need too much data, and I expect it will also save some CPU time.

[pseudografx]

Hi,

I hope that you will make it for the PC as working in an emulator or the real thing may be a bit clumsy. If you're worried about precision of POKEY emulation, I'm quite sure f0x would gladly cooperate with you on fixing this kind of issues in his ASAP library.

The environment may be simple, just a text-mode screen like in RMT.

 

Some features I'd find useful:

- support for half-speed tunes (i.e. calling the player once per two frames) - this may come in handy in scenarios where every CPU cycle counts.

- support for more than 4-speed tunes (if the player routine is fast enough). I've heard many 8-, 12- or even 16-speed tunes for the SID and the sounds were very nice so POKEY might benefit from this as well.

[ANTIQ]

A hardsynth / sample hybrid thing might permit higher sample frequencies....

I'm not sure what you mean with this sentence. Could you please elaborate a bit more? Do you mean 'higher' sample freqs than f.e. another sample engine? Or...

 

It's nothing very clever, I was just wondering if playing 2x16-bit hardware waves and 2 samples of frequency 2f would sound nicer than 4 samples of frequency f, say.

 

*cogs grind*

 

Does the "filter" give enough control of the waveform that it can be used to play a sample deeper than 4 bits by using a volume register and PWM?

[analmux]

Does the "filter" give enough control of the waveform that it can be used to play a sample deeper than 4 bits by using a volume register and PWM?

In a sense, yes.

 

The 1.79Mhz mode on both voice 1 & 3 produces sawtooth alike waveform. To be more precise, it's possible to produce both upward and downward sawtooth. Also changing sawtooth speed (wavelength/pitch) on the fly will give some more effective resolution. This sawtooth can be considered as self-modulating PWM, and it will be smoothened to finer voltage control because there's the integrating effect caused by the capacitors.

 

Just use 4bit PCM, for example on voice 3 (in volume-only-mode), and combine voice 1&3 to get sawtooth. Set volume of voice 1 to 1. The added/resulting/superposed signal will give us an effective sample resolution similar to 8 or 9 bit samples.

[analmux]

As I said, thanks @ all for comments & questions.

 

I think I'll do it in the following order:

 

• Work out concepts of "hardsynth player" engine (low-level)

• Work out concepts of data format of a hardsynth raw-data file (exported by mid-level tracker)

• Create mid-level tool "hardsynth tracker"

• Look at possibilities for a (high-level) user-friendly PC-tool (midi-import)

 

 

Finally, some replies (beware, long post):

 

 

...Of course another thing to consider is digitised sound....

...and yes, digi support would be great, too.

If I will do this, then I'd add an "insert point" in the player routine and possibly a command sequence track, but the sample module itself should be an external library, not included here. Then the user can add his own sample driver.

 

But, the tracker itself should not overwrite any AUDC reg which is in use by the sampler (or other SFXs), so, adding a masking procedure might be needed.

 

 

Yet another might be ahead-of-time processing of music and maintaining a buffer. So, for example if you have a particularly bad frame where you have barely any CPU time, you've got a buffer of notes that you can just do a quick lookup of, then when the load dies off a bit, you can do multiple tracker calls to build the buffer up again.

Yes, this is something I already considered. The "compute new values to stuff pokey regs" routine is one part, and it could run ahead f.e. 16 steps, and fill a temp ring buffer. Then only the reg stuffing routine is needed of course.

 

 

The "hardest" with hardsynth is to find a way for using the replay routines VBI independent.

The generators have to be programmed, like handling samples, just with less updates per second....

That's why the coder himself should think about which rasterlines are free. The mid-level hardsynth tracker, also running on real machine, should use the same rasterlines, when doing a playing test.

 

 

...So - what about making the sounds like sawtooth/triangle/other nonstardard ones as hardcoded (with user-defined envelope), and let the program decide which voices should be used for current instrument....

Sounds like a nice idea. Especially to be added to the high-level tool. Let's say, the high-level tool is for "composing a pokey tune for dummies".

 

 

For me is the most important it runs on Native atari 8bit....

Well, creating a pokey tune is so much easier when using a PC-tool. Of course the tune itself is supposed to run on a real machine. But, nevertheless, I'm planning to make a mid-level tool, called "hardsynth tracker", and this tool is supposed to run on the real machine. Only the high-level tool should be a PC-tool.

 

 

Please do it! And be sure to talk often to emkay.

Emkay & I had many talks already. We did also meet in real, already more than 5 yrs ago. I already have enough knowledge about pokey features, and how to control them.

 

 

If you make a PC tool for Windows, you can use C# (or VB) and make a Windows-Forms-App. Its pretty easy....But you need POKEY-emulation for JAVA then.

Fortunately, I know the basics of coding in C#. However, I'm not sure how to make proper usage of the "pokey.dll" library and other (gfx/windows-)dlls turning my tool into a user-friendly graphical/windows environment. Of course, any help from anyone here would be appreciated. Besides, someone already approached me, talking about possibilities of coding the tool together, or making two different versions, so...

 

 

Is there absolute no possibility to get the source from the RMT author and make a spin-off?

I could ask Raster, but I'm afraid it'll take many hours before I'll understand his source, and I can't demand an explanation from him, as this could also take many hours for him.

 

But, another thought might be: write an RMT2HST converter instead of a MIDI-import tool. Then it's just a matter of using an already existing PC-tool to do the basics of writing a pokey tune. Then convert to a Hardsynth track, do finetuning on the real HW itself.

 

 

Beside the straight programming of "Hardsynth", and digitizing, we have the possiblility to build interferences on the generators, to create the "3rd" type of sounds.

I already considered to add these features. Relative timing is not only needed for filtering/pulsewaves, but also other nice sync-alike effects.

 

 

...If you're worried about precision of POKEY emulation, I'm quite sure f0x would gladly cooperate with you on fixing this kind of issues in his ASAP library....

That's not my real worry. I'm more worried about coding the PC-tool itself. It might be difficult for me, and take more time than I expected.

 

 

...Now imagine, you could do various update speeds....

...Some features I'd find useful:

- support for half-speed tunes...

- support for more than 4-speed tunes...

See above:

 

• The update speed could be 1,2,3 or 4 times a frame (PAL 50 Hz / NTSC 60 Hz), but in theory also another arbitrary value

 

This feature is very important I think. It gives much freedom to the coder. The coder should decide which and how many scanlines will be used. In theory, the commands of the "hardsynth player" library can be called at any desired moment.

 

 

...thanks again...

 

any other ideas?

[Shawn Jefferson]

As far as the PC tool goes... "Build it and they will come." Build your player, tracker, etc.. on the Atari and the other pieces will fall into place, especially if other people see value in it.

[Rybags]

Another idea - the option for event driven sound/music.

 

Have a "watch list" of flag locations, when a bit is set, then a predefined sound effect or music piece is started.

 

Good for games for shot effects, end of level music etc. Rather than go through the hassle of initialising the environment for whatever you need, just set a flag depending on what you want done.

Would also work well with the "priorities/virual voices" ideas mentioned earlier.

[Mathy]

Hi Analmux

 

A lot of us Atari 8 bit users seem to again have chosen for the best computer, so the question is: Will there be a Mac-version of this PC-Tool?

 

sincerely

 

Mathy