Digidrums can be used with STarKos and Arkos Tracker.
But how do I create these Digidrums? I can't find anything when googling.
I thought there might be a tool that would let me convert a mono 8-bit sample on my PC so a digidrum. No?
Then how do I create these digidrums?
I'd like to know how to manage the .YM files with digidrums.
I know that the digidrum samples are stored within the file an that two phantom registers are used to play them, but I haven't found any info on how to do it.
Hm, I just stumbled across this: http://www.youtube.com/watch?v=0z-jGDOzwGQ
Maybe that's what we need to make those Digidrums?
I'll have a closer look.
Quote from: robcfg on 12:24, 25 May 10
I'd like to know how to manage the .YM files with digidrums.
I know that the digidrum samples are stored within the file an that two phantom registers are used to play them, but I haven't found any info on how to do it.
It seems that this information is not written out by Arkos Tracker, and the program to generate compressed ay for madram's player is not reading it at this time.
If you are using ayc/ym player and digidrums you need to merge the sources of the ay player with the starkos digidrum player together. T o have a player that can do both.
Then in your code have a list of:
<count>
<digidrum>
this will tell you the number of vsync to wait until you play the digidrum.
So it seems this is the only way if you are using madram's ayc player.
EDIT: I posted a message about it on www.cpcscene.com forum.
Quote from: mr_lou on 12:41, 25 May 10
Hm, I just stumbled across this: http://www.youtube.com/watch?v=0z-jGDOzwGQ (http://www.youtube.com/watch?v=0z-jGDOzwGQ)
Maybe that's what we need to make those Digidrums?
I'll have a closer look.
What are you looking for?
A tool that will convert samples on the pc into cpc compatible samples for arkos tracker?
I am already planning another example program that will play samples on the cpc (using ay chip), and maybe also one that will play using digiblaster now there is more interest. So I already have the need for a pc tool to create samples in a form the cpc can use.... so maybe I should write one?
Quote from: arnoldemu on 12:48, 25 May 10
What are you looking for?
I don't know exactly. I just found out that STarKos player routine can play "digidrums". These digidrums exists as *.spl files. So I'm curious about how to create these spl files. Maybe they can be created by some converter tool?
It just seems that, people speak about "digidrums" as if it's a well known concept for everyone. But googling digidrums or spl or similar, gives me nothing.
What is spl files? And how do I create them?
On the STarKos DSK, there's a DIGIDRUM.DAM source file, describing how digidrums are handled. Maybe that helps a hardcore coder (which I'm not).
Digiblaster is one thing, and would be great to have.
But the Digidrums in the DIGIDRUM example on the STarKos DSK, plays remarkably noiseless using standard AY-output. That makes me curious. Try the STarKos DSK and RUN"DIGIDRUM
Quote from: mr_lou on 13:10, 25 May 10
Digiblaster is one thing, and would be great to have.
But the Digidrums in the DIGIDRUM example on the STarKos DSK, plays remarkably noiseless using standard AY-output. That makes me curious. Try the STarKos DSK and RUN"DIGIDRUM
Technical:
In Starkos, the digidrums use 8-bit samples. The digidrum source mentions 8Khz or 6Khz but I guess any sample rate is possible. In either case, you have to modify the code to define the sample rate of choice. The 8-bit samples are converted at runtime into 4-bit volume values sent to the AY register. In addition in the digidrum sample code it has a hardcoded array which points to the start of each samples data and the size.
The digidrum data is raw 8-bit samples with no header. I can't see if the 8-bit samples are signed or unsigned. It appears they are probably unsigned. But the only way to know is to play them and try them out.
Digiblaster:
Digiblaster uses 8-bit samples also, but I think they are signed 8-bit. The digiblaster code also has a fixed playback frequency, and you must modify the code to set the rate.
robocop style samples:
Robocop uses converted 4-bit samples. Where two samples are packed into 1 byte. Here also the sample playback rate is fixed and defined in code.
So you'd need special code to make them.
EDIT: Since the digidrums source code comes with starkos, it would be possible to modify it to output samples to the digiblaster.
So with this method you would have 4 channels of sound, 3 AY channels, and 1 digiblaster channel.
EDIT2: To create them the steps would be:
1. record sound or use existing wav on pc.
2. use audacity or goldwave to change sample to 8-bit mono unsigned at 6Khz (default for digidrums code it seems).
3. now you need that converter to read the wav and strip headers etc. (I may be able to cut down the code for samp2cdt or arnold sample reading to do this).
Quote from: arnoldemu on 13:58, 25 May 10
3. now you need that converter to read the wav and strip headers etc. (I may be able to cut down the code for samp2cdt or arnold sample reading to do this).
The Digitracker DSK contains a converter for both MODs and Samples. It can convert WAV into SMP files.
Do you think these SMP files can be used directly as digidrums? In other words, are these SMP files the same format as the two SPL files found on the STarKos DSK?
Quote from: Targhan on 18:22, 25 May 10
They are 8 bits unsigned wav files. I guess they are converted on the fly by my digidrum code.
I've tried loading an SPL file into Milkytracker now, and it appears to be a signed wav file with reversed signing and some other header stuff in the beginning. Milkytracker loads it fine. Then I can change signs to make it a play correct, but the first 130-140 bytes seems to be header stuff.
Then I tried the same with an SMP file from Digitracker. It appears to be an unsigned wav, also with some header stuff of 130-140 bytes in the beginning. (No swapped signs).
So it seems I can complete half the job using Milkytracker, by swapping signs before saving the file. But that doesn't seem to be enough.
Any good software on PC can convert any sample to 8 bits unsigned sample (Soundforge being the one I use). Be sure to save as "Raw" so that no header comes in your way.
Now keeping all the samples in 8 bits or converting these to 4 bits is a choice of yours, depending of what you're doing. For digidrums, it's fine. Remember that only 4 bits are used in the end by the PSG volumes registers !
If I remember correctly, digitrakker samples are kept as 7 bits in memory, so that (7+7+7)/2=8 bits, that are then converted through a logarithmic table to get a 4 bits sample.
Quote from: Targhan on 19:41, 25 May 10
Any good software on PC can convert any sample to 8 bits unsigned sample (Soundforge being the one I use). Be sure to save as "Raw" so that no header comes in your way
That's just the thing I'm writing. The SPL file appears to infact contain a header.
If an SPL file is merely an 8bit unsigned wav file saved raw, then I should be able to load an SPL file as an 8bit unsigned raw file using e.g. Audacity, right?
But if I do that, there's clearly some header stuff in the beginning of the file that's not audio. Whatever this header stuff is, it will be missing from the files I save on the PC.
I can also load it as an 8bit signed raw data, which results in signing being swapped - and there's still this header stuff in the beginning.
See the attached image. It's clear that the audio-data doesn't begin right away.
Conclusion: SPL files must contain some kind of header.
I guess I did these SPL files. I don't remember how they were done, but if they seem to have a header, that's because I was too bored/lazy to take care to remove it ! Anyway, who cares about a few bytes when you are sending 8000 bytes per seconds ?? Especially if using digidrums :) ! (I didn't look at the source I provided, but you can skip the headers easily in the EQU consts at the beginning).
If you load a headerless format into a good sound editor on PC, it will ask you how to treat it : samplerate (44khz...), bitrate (16/8 bits), Mono/Stereo, and so on. So you can convert your audio stream to WAV or anything else. I really don't know what you're trying to do with these so called "SPL" files, that's just an extension I provided so that people know they are samples. Don't care about that. On CPC, your code is linked to the samples. If I want a 8000hz sample, I won't have a flag telling me so. I'll CODE something that will have to be fed with such samples.
Trg.Aks
I also add that the so called "header" is no interpreted at all : its values are played through the AY like anything else (very dirty !). SPL is really not a format at all. The STarKos digidrums code provided just need sound streams. Now if you want to make your own format and stuff (for whatever reason), you *can*. That's why I made a player that doesn't handle digidrums on its own : it just signals the coder that *something* has happened, whether it be "event signals" or "digidrum". Then, the coder does what he want with it.
Alright then. :-)
So the answer to the question "How to create digidrums" is:
You save the audio data as 8bit mono unsigned raw files, and load those in your player routine.
I will experiment now.
>load those in your player routine
Or in yours :).
Trg.Aks
Quote from: Targhan on 06:50, 26 May 10
Or in yours :) .
Nah, I think raw is the best and smallest way of doing it.
Also, I'm no CPC coder, so I need to use existing routines. And why not use the routines from the master himself? :D
Quote from: mr_lou on 21:27, 25 May 10
Alright then. :-)
So the answer to the question "How to create digidrums" is:
You save the audio data as 8bit mono unsigned raw files, and load those in your player routine.
I will experiment now.
Great.
Knowing that a pc program can write the samples in raw form saves a lot of work.
I still plan to make a sample player that uses 4-bit samples as an example for others to see, but this info will now save me lots of time generating the original sample data.
>And why not use the routines from the master himself?
The code is not optimised, it was more a tutorial about digidrums. But if that's the only thing you're doing in a frame, it's enough.
Trg.Aks
Quote from: Targhan on 18:53, 26 May 10
The code is not optimised
I'll leave that to the real coder, if I ever manage to create something using digidrums. For now I just want to experiment and see what I can do with it.
Currently still at the first step: Finding a tool for Linux that lets me save my mono 8bit wav file as unsigned raw.
Ok, gotten a little further. Have tested with 3 audio forms:
1) 8bit unsigned raw
2) 8bit signed raw
3) 8bit unsigned wav
When testing I'm just using the DIGIDRUM basic loader from the STarKos DSK, and replacing the loading of the BDLXS.SPL with my own file.
In all 3 cases it seems to load fine, but it only plays the beginning of the file, as if digidrums always have a certain length. Can this be? Are digidrums always only the same length as a single row in the SKS file?
Mmmmh... do you know what you're really doing ? :)
The AY play samples is done by switching volumes very quickly (just like any sample player on any machine), from 0 to 15. That's what unsigned signal is doing. Signed signal would mean from -8 to 7. If you send such values to the AY, it won't mean a thing to him, ignoring the highest quarter (-8 -> #f8 in hex -> Hardware envelope ON as bit 4 is ON, so volume is ignored... Nothing musical).
Like I said earlier, the WAV header is tiny, so you will probably not notice it at the beginning of a digidrum sample (you WILL if you're playing a musical instrument, like a piano, and so on). Using a RAW file is cleaner, and shorter.
Also, I suggest you have a look at the source file of STK_Digidrums.asm: the length of each sample is indeed hardcoded. You have to compile the source if the size of a sample changes. This has NOTHING to do with the SKS file, or the STarKos player which only send MESSAGES to anyone who wants to hear it (Digidrum.mxm captures the message).
In StarKos 1.2, STK_Digidrums.asm :
ADDRUM equ #2000 ;Address of the samples
ADSNARE equ #2500
SZDRUM equ #280 ;Size of the samples
SZSNARE equ #1f0
Address and size of each sample are hardcoded.
Trg.Aks
Quote from: Targhan on 20:50, 26 May 10
In StarKos 1.2, STK_Digidrums.asm :
SZDRUM equ #280 ;Size of the samples
SZSNARE equ #1f0
Address and size of each sample are hardcoded.
Ah bummer. I guess there's no way around the compiler for me then. :-X
Thanks again.
Why ? You can use another compiler if you want. I guess SJasmPlus works on Linux and could compile that easy.
"the compiler" = any compiler
What I mean is, that I prefer to avoid the coding/compiling part. But I'll probably figure it out. After all, I did manage to code Sort'em a while back.
Anyway, next silly question:
Is there any hardcoded value that sets the frequency as well? For example, the wav file I'm experimenting with is 4000hz.
EDIT: I see line 176 and 189 has values for 8khz and 6khz. I don't suppose 4khz would happen to be 80 in line 176 and 160 in line 189?
That's really a crappy code :). The sample code takes 28 cycles, to which you add NOPS. For 8 khz sample, a sample must be played every 128 nops. For 16khz, every scanline (64 nops). The calculation is up to you :).
I however decreased these number because of the STarKos player, which takes about 35 scanlines.
Quote from: Targhan on 21:42, 26 May 10
That's really a crappy code :)
Er, what is? Your example code, or my estimate?
Please understand, that I have no idea what a NOPS is or the likes. I compose music. I can't code assembler.
Just now I tried compiling your code with pasmo, resulting in having to insert ; everywhere to comment out the....comments. I'm using the DAM variant (instead of MXM), since pasmo seemed to like that one most. (I have no clue what DAM or MXM is either).
I'm only interested in one thing: Experiment to see what kind of quality I can squeeze out of digidrums. So I'll see if I can edit that source code now to contain only 1 sample, and then take it from there.
Oh, don't worry, I was talking about my code :).
You should use the .asm that you can find on the STarKos website, I think it's cleaner.
Quote from: Targhan on 22:17, 26 May 10
Oh, don't worry, I was talking about my code :) .
You should use the .asm that you can find on the STarKos website, I think it's cleaner.
I took a look at the source that's on the website, but trying to compile that with passmo gives me other problems, like it complains that the label "nolist" has already been defined...tsk.
I've had somewhat success with the DAM source. But both the sample and tune is playing way too slow. I suspect it's because the track I'm using is a 100hz one, and the default playback is 50hz? But I can't find anywhere in the player source where I set this.
Anyway, time to call it a day. G'nite.
Remove the "list"/"nolist", they're just Maxam mnemonics to start/stop the listing display.
About the frequency, yes, only 50hz. If you want 100 hz, the most simple way to do this is to remove the VSync loop and play twice less samples ! This way, your song will be "almost" at 100hz.
Trg.Als
Nevermind.
I was using the PLAYASM9.BIN from a previous version of STarKos, and that seemed to be the cause.
Generating a new player with GP solved it at least.
Now to find out why my samples are just noise.... ::)
Been experimenting quite a bit now. My thought was that I could put a chord into the digidrum, instead of a drum.
So I've tested with a simple square sample now, and find that it's not precisely playing back at 8khz.
Is there any way of knowing precisely what the playback frequency is, when we use 160 samples per VBL and waiting 80 nops?
Yes. Count the cycles. In theory : (64*312) / time of the replay routine (=28 cycles for the replay + the nops) * 50. So if you're playing every scanline (every 64 nops), you'll get a 15600hz replay frequency.
However, with this code, it will be lower, as we lose some time playing the STarKos player. To play a musical instrument, 8Khz is not a lot. And like I said earlier, it will sound bad because while the STarkos player is called, no sample is played. That's why this code is only useful for digidrums. For example, for the "landscape" part of the Demoizart, you can hear both digi+FM. But the players I did were micro coded to allow me to play the samples EVERY scanline. You may not be able to do what you want with the current player. Switching to Arkos Player tracker may improve the result as it is faster, but...
Oh by the way, did you make sure that you were increasing/decreasing the "ld c,120" just above the PTSPL label ? It's how many sample you're reading per VBL. It has to be as high as possible ! (the raster must fill the screen)
Quote from: Targhan on 10:45, 28 May 10
Iit will sound bad because while the STarkos player is called, no sample is played. That's why this code is only useful for digidrums. For example, for the "landscape" part of the Demoizart, you can hear both digi+FM. But the players I did were micro coded to allow me to play the samples EVERY scanline. You may not be able to do what you want with the current player.
So code me another player you lazy geek. :)
I hear what you mean. It's quite easy to hear that the sample-playback is constantly interrupted. But besides that, there's also way too much noise. I did expect noise, but not this much.
I was thinking, that if the sample was simple, like e.g. a square synth, then we'd be "safe". So I tried making a chord of square synths, giving roughly 5 different positions of the wav.
So I changed the CONVTAB so that there only was 5 volumes.
Everything from 0 to 48 = 0
Everything from 49 to 80 = 6
Everything from 81 to 144 = 9
Everything from 145 to 176 = 12
Everything from 177 to 255 = 15
I thought I could get a cleaner square sound this way, but no. I'm drowning in noise.
So I see what you mean about the digidrum feature mostly being useful for actual drums, and not much else.
Quote from: Targhan on 10:45, 28 May 10
Oh by the way, did you make sure that you were increasing/decreasing the "ld c,120" just above the PTSPL label ? It's how many sample you're reading per VBL. It has to be as high as possible ! (the raster must fill the screen)
Yup
My advice is :
- You code another player by yourself :).
- You could also use a very fast player like madram's AYC player. It's more stable and takes about 10 scanlines (you'll have trigger the digidrums by yourself though).
- You ditch the StarKos player and do samples only. Prodatron manages to get a "decent" quality in the Digital orgasm thanks to that (though the music is cut by the 6 interruptions code, fortunately they're tiny, except for the scroller).
Trg.Aks
I wouldn't know how to code my own player.
I'm in the process of getting myself a Digiblaster, and then I will experiment with Digitracker. Till then I just wanted to see what STarKos could do. Now I know.
Thanks for the help.
Maybe you should PLOT your samples on the screen and see if the wave-form you get is as you expect it to be. For example, the small program below will load a sample and display the first 640 values (enough to do the check).
10 MODE 2:MEMORY &3FFF:LOAD"bassdrum.spl",&4000
20 FOR x=0 to 640:DRAW x,PEEK(&4000+x):NEXT
With drums, the waveform usually is clearly recognizable. So, if you don't see it, call Houston.
Also, do not waste your time trying to produce a normalized sample for the AY. The logarithmic DAC outputs will mutilate it anyway. Do not hesitate to boost heavily (read: saturate) the volume of your sample.
Quote from: Grim on 16:21, 28 May 10
Maybe you should PLOT your samples on the screen and see if the wave-form you get is as you expect it to be.
That was a good idea. I expanded that program, so that it poked new values in order to get a more clean synth, and then saved the file again. There's still way too much noise though, and I don't think it improved anything, because the converter-table in the source should take care of that part already...
But the plot showed me that the file was as it was supposed to be.
Quote from: Grim on 16:21, 28 May 10
Also, do not waste your time trying to produce a normalized sample for the AY. The logarithmic DAC outputs will mutilate it anyway. Do not hesitate to boost heavily (read: saturate) the volume of your sample.
mkay thanks. I'll test this.
Targhan, can we have some specs for the SKI format? I want to experiment creating instruments externally.