Hi!

I am working in KAROSHI'S PSG TRACKER, and you can get the first beta of the SAMPLER at http://www.robsy.net

But in order to continue my efforts I want to share my design ideas for both the sampler and the tracker.

The SAMPLER enables you to edit PSG SOUNDS. In these sounds, you can select the AMPLITUDE LEVEL (volume, from 0 to 15 and MODULATED), the NOISE FREQUENCY (divider from 0 to 31), TUNE CHANNEL ON/OFF, NOISE CHANNEL ON/OFF, sample length (from 1 to 30 V-blanks), HARDWARE ENVELOPE SHAPE and PERIOD and TUNE SETTINGS (alterates frequency divider from -999 to +999 units). There will be also a 1 octave keyboard to test the sounds in any of the 8 supported octaves. Is this enough? Any other idea to complete the sample editor?

The TRACKER is not coded yet, but I like to include a SOUNDTRACKER (Spectrum) alike interface and format. This format is like follows:

N#o SO Xnn

This means:

N: note, in english notation: C,D,E,F,G,A,B
# or -: sharpen or normal note
o: octave, from 1 to 8.

S: sample to use, being 0 a plain sample, and from 1 to F the possible samples.
O: ornament, a kind of tune variation that can be set for any sample independently.

X: special command
nn: parameter for the command

Typical commands are:

-Replay speed up
-Replay slow down
-Loops
- Ideas?

Also it will be possible to set repetition for samples in the tracker, setting the repetition start point and the times to be repeated.

This would be 3 bytes for every channel entry: 9 bytes for entry.

Ideas? Suggestions? It can be a good PSG tracker, don't you think so?

Kind regards,

Ed Robsy

uhm, just to get things right: do you mean 3 squares and noise, or 'samples' ?

(as in: pcm)

Of course, it is 3 channels + noise + hardware envelopes. "SAMPLE" is the name to refer to a single-channel sound with all its attributes, that later can be used in the tracker part. I used SAMPLE because it is the usual word in the 8-bit scene. Guess that "SINGLE CHANNEL SOUND PATTERN" may be clearer...

Perhaps it would be possible to add 1-bit PCM using not the PSG but the key-click. Weird.

I would avoid the word 'sample' since the psg can playback samples ..

'sound-editor' or 'instrument editor' etc. sounds better/clearer

Yes, 'INSTRUMENT' is a good choice.

The problem with PSG 4-bit samples is that they need a lot of memory, and even worse, a lot of CPU time, and even though, their audio quality is rather poor. Better stick to "normal" PSG processing with a wise approach.

ok, well, to get back OT:

Make an MBFM/MBWave importer, including all vibrato/slide stuff, and if possible make a software envelope based on the carrier-envelope of FM voices (or the envelope of the samples from mbwave).

This way, you can convert an MBFM tune to PSG so that you don't need to re-compose everything by hand when you want PSG support. Ofcourse the actual MBFM tune, (or at least the first 4 channels (3+noise) should be made with PSG playback in mind.

There should also be an advanced sfx editor to make drumsounds etc.

Yet better, there should be more than 3 input channels in the tracker to allow some comfort while editing.

In many cases you can add a snaredrum to a bassline channel, however you might want to transpose the basschannel for obvious reasons, and to prevent the snare to be transposed aswell, you might want to put the snare on another channel. So, the 2 visual channels are just 1 channel internally. If you use 6 channels by putting notes on them, then you obviously only hear 3 channels at once.

Ofcourse, a releaseversion of a tune has only 3 channels, this 6 (or more) channel stuff is purely for editing purposes.

Hello.

I would call "a single-channel sound with all its attributes" a SAMPLE, as it's done in the CPC, C-64, ZX Spectrum, Atari, etc ... scene. There's no need of playing digitized sounds in a tracker, though it can be implemented, for instance, in the Atari scene sometimes they play digitized drum sounds since you don't need much quality of sound for a drum; this is called DIGIDRUM -though I think it's not necessary.

In my opinion, there's no need of changing the terminology related to AY-3-8910/12 trackers that was "established" more than 15 years ago.

About the sample editor, you didn't mentioned if there was a loop or not. For instance, in Penguin Race the drum is 6 v-blanks long with no loop, but there are instruments which need to be repeated (once they played all the v-blanks) from a certain v-blank. Even the ornament editor needs this to be implemented, and the pattern editor, obviously.

In the tracker there's a very important parameter missing: envelope. It would be good to set five parameters for every channel:

1-note (C-1 to B-8)
2-sample (0 to f; if you want to establish 16 samples per song, though it could be 32; from 0 to v, which would be 5 bites long, instead of 4)
3-envelope (0 to f)
4-ornament (same as sample).
5-volume (0 to f)

And, after this and in the same line, I would add to the tracker the envelope values (registers 11 and 12), in case any sample uses it, since we already know the kind of envelope (R13) from the 3rd value given to the channel.

There's something else, that almost nobody uses, but that could be easily implemented and it's the noise value (appart from the noise values given in the sample editor).

All this could be something like:
----chan A-chan B-chan C- env. -noise
00|1.2345|1.2345|1.2345|R11R12|R6

In every channel part of the tracker you could add some special commands, as you say. For instance, the value 1 could be slide down (and a value for the speed of the slide), 2 could be slide up, etc ... so you should add these values to the tracker in every channel.

I have stopped my project about this for the moment (whenever I think about all this I feel sooooo lazy), that's why I have told you to cooperate with you, in a private e-mail, and make a very good tracker. It's really hard to write the values manually in an MSX.

Regards.

I prefer the term 'instrument', as a 'sample' is just a binary representation of a (collection of) measurement(s) of sound.
I wouldn't be surprised if the term 'sample' was based on the real samples used in the pioneering amiga trackers.

Wolf has a point with converting from moonblaster, as you don't need to write another tracker. Just a conversion program is enough. On the other hand, moonblaster as an editor is fairly limited. There are no per-step effects, etc...

Personally I'm a big fan of MML (Music Macro Language) representation, as used by MSX BASIC/FM BASIC and programs like muSICA, MGSEL, OPX, etc... All the major softwarehouses in japan (konami, microcabin, t&e soft, falcom, etc) use MML based music players.

Some of the advantages to this approach are: compact (small songs), efficient (no processing empty steps or empty effect data), accurate (very high resolution sounds possible).
A disadvantages is that it's difficult to edit MML if you're used to steptime trackers, although this can be solved with conversion programs.

Just my 2 cents

This is the idea, yes. And of course I would like you to join the project, even if I do not know when would I have spare time to continue with it. I hate the exams!

The only problem is that the music created with a tracker like this would have high memory requirements, and perhaps it wouldn't be suitable to be used in game development. I don't know, but I want to try.

Welcome on board, Alfonso!

Kind regards,

Ed Robsy

something that would be neat for the editor is to support file formats of other machine's tracker (speccy tracker for instance). those formats have been used for years aand are way optimized so why re-invent the wheel ? not to mention it would allow to play the thousands already available speccy tunes on the msx.

You might wanna check www.thefuzz.nl
download->docs->oracle
for some documents containing FX, format etc. Maybe there's some info interresting enough to use on your tracker

ro

Quote:

something that would be neat for the editor is to support file formats of other machine's tracker (speccy tracker for instance). those formats have been used for years aand are way optimized so why re-invent the wheel ? not to mention it would allow to play the thousands already available speccy tunes on the msx.

and don't forget the ATARI format (probably the same shit).. 1000's of tunes

MML/Tracker.

There's more versatility with MML than with a tracker, since you can edit everything in every v-blank (though it can be done with a tracker as well, at least with the ones I've seen). The result is a big amount of raw data to be sent to the AY registers in every v-blank.

The raw data obtained with a tracker it's much more smaller since the tracker player is the best compressor available, I think it's natural:

MML: You write raw data directly to the AY registers in every v-blank. So if you
have a 30 seconds song and you update every 14 registers 50 times a second
(50Hz) you have a song of:

14 registers X 50 v-blanks X 30 seconds = 21.000 bytes!

Tracker: You write a new line in the tracker every X v-blanks, depending on the speed
(which is the number of v-blanks). Being 2 the speed, which is too fast, the size
of the datas would be half of the datas obtained with MML. But it's, in most of
the cases (or all) much smaller; speed=3, 4, 6, ...

Being able to modify everything with samples and ornaments, and even special commands (sliding, for instance), we have complete control of the AY and with an esay interface; the tracker. You can even choose speed=1, so it's like MML (even the size of datas obtained, just in this case).

The problem, as Robsy states, is the speed, so it would be interesting to save datas for a player (like the one in the tracker which interpret tha datas -time consuming) or to save the song in raw datas (MML) for games, obtaining a big amount of data but with a fast player which send the raw datas to the AY registers.

What I do is to send raw datas but try to 'compress' a little bit with something like:

We have IX loaded with SONG.

PLAYITSAM: DI
LD A,0 ;R0
OUT (#A0),A
LD A,(IX+0)
OUT (#A1),A
LD A,2 ;R2
OUT (#A0),A
LD A,(IX+1)
OUT (#A1),A
LD A,4 ;R4
OUT (#A0),A
LD A,(IX+2)
OUT (#A1),A

LD A,3 ;R3 R1
OUT (#A0),A
LD A,(IX+3)
AND #0F
OUT (#A1),A
LD A,1
OUT (#A0),A
LD A,(IX+3)
RRA
RRA
RRA
RRA
OUT (#A1),A
... ; ETC...
EI

; 0 2 4 1-3 5-13 8-6 9-10 11 7
SONG: DEFB 148,#90,046,#11,#1C,%10000111,#FE,#32,%00101000
DEFB 149,#F0,036,#11,#10,%10000110,#FF,#00,%00101000
DEFB 151,#50,056,#12,#10,%10000000,#ED,#00,%00101000
DEFB 148,#B0,041,#12,#10,%10000100,#EE,#00,%00101000
DEFB 149,#20,051,#13,#10,%10000011,#ED,#00,%00101000
... ,ETC... (10th part of a second song!)

Since R1, R3, R5 and R13 are 4 bits long I put them together by two.

Well, with R8 and R6 ... since noise (R6) is not going to be bigger than 3 bits (0 to 7) and I'm using envelope in channel a (R0 and R1) I use the first 3 bits of that byte for noise and then read the other 5 bites, wich will be 10000 for envelope or 00000 for silence (together with the R7) at the end. R7 is writtne in binary because I have to see MANUALLY whats going on so I turn oof (1) or on (0) the bits of noise and/or tone.

R9 and R10 are together, since values are 4 bits long (like R1-R3) for the volume; I won't use envelope here, just in the first channel, otherwise I couldn't put together R9 and R10 -with envelope they would be 5 bites long.

R12 is set to 0 since I don't use it and R11 is 8 bits long.

I REALLY NEED A TRACKER, PLEASE. THIS IS JUST PAINFUL. Imagine, as I said before, a 30 seconds song ... I can't.

A tracker would be the better option since there's already an MML type tool (musica). A tracker has less features compared to MML yes, but I kinda accept that when I compare the speed a tracker has.

For development speed, conversion from MBM, MBWave and MBFM is prefered. I wouldn't mind if there's only a converter instead of a whole new program.

PSG development in general is good when you consider that a lot of msx users in various countries don't have an FM-Pac/Mus.Mod./Opl4.

ps. if old retro computers talk about oscillators as if they were samples, then they were wrong all the time It seems that we're talking about oscillators rather than samples, when we're talking about 3 squares and noise. And even when the program supports real samples played-back on the PSG chip, then still I prefer the term 'instrument'. Whether this isntrument is an oscillator or a sample depends on the instrument editor.

Quote:

The raw data obtained with a tracker it's much more smaller since the tracker player is the best compressor available, I think it's natural: MML: You write raw data directly to the AY registers in every v-blank. So if you have a 30 seconds song and you update every 14 registers 50 times a second (50Hz) you have a song of: 14 registers X 50 v-blanks X 30 seconds = 21.000 bytes!.

As I stated compactness as being one of the advantages of MML, you're terribly wrong with your calculations. With MML you do not write raw data to registers at all, and it's automagically compressing the data.

That 'speed trick' works the same in MML, but MML has additional compression. As I stated, it does not process or store empty steps, as a tracker would (moonblaster compresses multiple empty steps per line).

As MML uses sequences and not full patterns, a bassline can be stored just once, while a tracker stores the bassline every time one of the other channels differs.

Compared to tracker songs, the same song in MML is usually ~4 times SMALLER!