QTM (QTheMusic) v1.45 released

discuss general risc os software applications and utilities
Related forum: adventures


steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

QTM (QTheMusic) v1.45 released

Post by steve3000 »

For those of you who have in interest in .mod music, the latest version my QTM module is now released!

QTM is usually hosted on Jeffrey Lee's website, but as he's away at the moment, please find the .zip attached here (I hope that's allowed by the site?) containing QTM v1.45 and QTMDisplay. QTM v1.45 works on every RISC OS computer, from the earliest ARM powered Acorn machines (A305 running Arthur OS 0.3) to modern Beagleboards and Raspberry Pis running RISC OS5.

Included with this release is QTMDisplay v0.65b - this is the first release of my tracker display for QTM, it has been tested on RISC OS 3 to RISC OS 5, and runs at full speed even on old ARM2 machines. On the latest RISC OS hardware, it features a slightly more colourful mode (spot the difference!)... See pictures below:

Raspberry Pi 32bpp mode:
32bit colour, Raspberry Pi version
32bit colour, Raspberry Pi version
Standard 16-colour version:
4bit colour, standard version
4bit colour, standard version
Enjoy!
Steve
Attachments
qtmv145.zip
QTMv1.45 and QTMDisplay
(253.09 KiB) Downloaded 123 times
Zarchos
Posts: 2355
Joined: Sun May 19, 2013 9:19 am
Location: FRANCE

Re: QTM (QTheMusic) v1.45 released

Post by Zarchos »

=D> Thanks ! =D>
pkersey
Posts: 207
Joined: Wed Feb 06, 2013 11:22 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by pkersey »

:shock:
Kudos! =D>
sirbod
Posts: 1228
Joined: Mon Apr 09, 2012 9:44 am
Location: Essex
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by sirbod »

Yay, we can finally release Chuck Rock for RO3.1 which I'll do along with the ADFFS beta that adds the ARM3 JIT for StrongARM and the Pi.

I'm aiming to have this version of Chuck Rock running on the Pi for the release, it's close although I found a few bugs last night that I need to resolve first. Incidentally, the link with QTM1.45 is that extensions were added so MUS2QTM can pass the sample info back to the game - which animates the band on the title page.
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

hi there

something that might interrest you :

https://github.com/arnaud-carre/LSPlayer

LSP (Light Speed Player) is a very fast Amiga music player. It can play any MOD file and outperforms all existing Amiga music player in speed

Image
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

Wow, what a thread revival, didn't realise it had been so long ago :D
ericde45 wrote:
Thu Mar 11, 2021 6:53 am
LSP (Light Speed Player) is a very fast Amiga music player. It can play any MOD file and outperforms all existing Amiga music player in speed
Interesting, but this is for the Amiga though, not the Archimedes, and is only compared to other Amiga based players. I don't have an Amiga so can't test this out, but having looked at the code I can see it only plays the MOD notes and doesn't support music effects. This will not reproduce most existing MOD music correctly, only those tracks written without extensive use of effects. And the custom file format it uses would seem to increase the size of the MOD file, for ease of playing...which looses the benefit of a smaller code player.

Avoiding use of music effects and stripping this code from the player was a standard demo optimisation BITD, I have a cut-down QTM like this somewhere, and with a good musician writing the MOD, it can still sound amazing.
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

are you sure that some effects are removed ?
the coder behind this work is a top coder, currently maybe the best coder on ST
he did this :

On ST :
https://www.youtube.com/watch?v=XJKDb4ByZ7Y


On Amiga :
https://www.youtube.com/watch?v=yRiFhDFFt58

edit : for what i understood, he changes the module to only keep the used effects. and in the fastest version, he generates the code to play each note/effect with code directly.
thecellartroll
Posts: 359
Joined: Thu Nov 24, 2011 10:43 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by thecellartroll »

What a most excellent thread to come across while loading an A5000 partition with MOD files :D

QTM is the best player I've found. This is a newer version than I had scrounged from an old disk.
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

thecellartroll wrote:
Fri Mar 12, 2021 1:59 pm
What a most excellent thread to come across while loading an A5000 partition with MOD files :D

QTM is the best player I've found. This is a newer version than I had scrounged from an old disk.
:D Glad you like it! If you haven't already bypassed the A5000's sound filter, you might want to try this for much clearer sound: viewtopic.php?f=16&t=13630

And this reminds me, I don't think I ever released my !Tracker to QTM module converter...must put that on my to-do list...
thecellartroll
Posts: 359
Joined: Thu Nov 24, 2011 10:43 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by thecellartroll »

steve3000 wrote:
Sat Mar 13, 2021 6:56 pm
:D Glad you like it! If you haven't already bypassed the A5000's sound filter, you might want to try this for much clearer sound: viewtopic.php?f=16&t=13630

And this reminds me, I don't think I ever released my !Tracker to QTM module converter...must put that on my to-do list...
Interesting! I am using the external speaker at the moment. I do have the A5000 connected to a display with really nice audio, but the audio from the A5000 headphone socket is really quiet, requiring the volume almost full on the TV.

I have a Gotek coming for the A5000 so next time I dismantle it I'll do your modification :D
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

Hello all and Steve :)

i have 2 questions regarding QTM:

- for what i understood from QTM's source, it does not use the sign in the mu-law sample values, why ? Amiga's samples are signed, would'nt be better to keep the sign, and have a larger range of 8 bits values ?

- in the RasterMan version of QTM, it uses 416 bytes per VBL, which means 20800 HZ frequency, and 48 us as Risc OS frequency, which gives 20833 HZ. that's not perfectly the same value, so why is it using this value instead of for example 400 byts, 20000 HZ, 50 for frequency value for Risc OS ? did i miss something in my calculations ?
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

ericde45 wrote:
Wed Jun 23, 2021 7:58 am
Hello all and Steve :)

i have 2 questions regarding QTM:

- for what i understood from QTM's source, it does not use the sign in the mu-law sample values, why ? Amiga's samples are signed, would'nt be better to keep the sign, and have a larger range of 8 bits values ?
I'm not sure where you get that impression from, take a look at the conversion table code in QTM_Mod "setlinlogtab" - this creates a lookup table to convert the full 8-bit linear range (-128 to +127) to signed 8-bit mu-law, by using the RISC OS internal 32-bit linear to logarithmic conversion code and shifting the 8-bit linear byte into the top of the 32-bit word used by the RISC OS calculation. It would sound terrible if you chopped the sign bit off... :shock:
- in the RasterMan version of QTM, it uses 416 bytes per VBL, which means 20800 HZ frequency, and 48 us as Risc OS frequency, which gives 20833 HZ. that's not perfectly the same value, so why is it using this value instead of for example 400 byts, 20000 HZ, 50 for frequency value for Risc OS ? did i miss something in my calculations ?
Yes, you missed that the VBL timing of RISC OS screen modes is not 50.00 Hz, it is 50.0801282 Hz, and the RasterMan version of QTM drives the buffer fill off the VSync. Therefore 416 * 50.0801282 = 20833.333 Hz.

In fact most 80's/90's computers driving 50Hz CRTs use ~50.08 Hz VBL timing. The calculation goes something like this: 312 scanlines in a full PAL frame, with line output at 15625Hz = 64uS/line so 1/(312 * 64 uS) = 50.0801282 Hz.

To allow music to play correctly without distortion when using RasterMan (which disables any interrupts that occur during screen output phase), the RasterMan version of QTM needs to fill the sound buffer only during VSync, which, per the above calculation will be at 50.0801282 Hz.

This is achieved by setting a sound output frequency of 20833.33Hz, with a buffer of 416 bytes/channel, and (as above) 416 * 20833.33Hz = exactly 50.0801282Hz

...and because the sound and video are driven by the same chip (VIDC) off the same 24MHz clock... it works nicely :)
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

ok

regarding the sign bit i got this impression from the following code in QTM:
2608 .setvoltabs

2609 MOV R0,R1,LSL#(24+1) ; R0 = volume en cours << 25 ( 7 bits pour la valeur 64 + 25 bits de precision)

2610 SWI "XSound_SoundLog" ; R0 => 8-bit signed volume-scaled logarithm

2611 RSB R0,R0,#255 ; R0 = 255 - R0

2612 AND R0,R0,#%11111110 ;stops odd/even changes (ie. +/- sample changes)

but as this is the calculation of the volume table, i understand that the volume table is mixed with the linlogtab table, so this is to avoid to calculate twice the sign i suppose.

anyway the global sound system of the Archimedes is really a mess. mu law, only one DMA, pfffff :D
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

ericde45 wrote:
Thu Jun 24, 2021 10:16 am
ok

regarding the sign bit i got this impression from the following code in QTM:
2608 .setvoltabs

2609 MOV R0,R1,LSL#(24+1) ; R0 = volume en cours << 25 ( 7 bits pour la valeur 64 + 25 bits de precision)

2610 SWI "XSound_SoundLog" ; R0 => 8-bit signed volume-scaled logarithm

2611 RSB R0,R0,#255 ; R0 = 255 - R0

2612 AND R0,R0,#%11111110 ;stops odd/even changes (ie. +/- sample changes)

but as this is the calculation of the volume table, i understand that the volume table is mixed with the linlogtab table, so this is to avoid to calculate twice the sign i suppose.
Yes that’s the scaled volume table, it is deliberately 7-bit unsigned to allow subtraction of these data from the signed 8-bit logarithmic sample data, without modifying the sign of the sample data, because that would cause a ‘pop’ as the waveform breaks.
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

ericde45 wrote:
Thu Jun 24, 2021 10:16 am
anyway the global sound system of the Archimedes is really a mess. mu law, only one DMA, pfffff :D
Ah yes, it certainly makes you work a lot in software!
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

a small update:
i am now at the step where i am able to fill a 4 voices dma buffer, with 4 samples and volume for each voice, in 1 pass
it takes 7,7% of the cpu time @ 20833,33 khz ( 12 mhz cpu)

the mixing code uses all registers, and have all 4 volumes in 1 , using lsr/lsl, and the incremented byte sources are offsets related to the beginning of the sample. This way i don't have 1 register per instrument, but 1 register for the base address of the samples.

not sure i will keep running it @ 20,8KHZ as Amiga's samples from the old times are at maximum 15 khz. most of the samples were around 8-11 khz.

and of course, no risc os running in the background :)

regarding DMA buffers, i just added 4 KB to video memory and made my nest here.
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

ericde45 wrote:
Wed Jun 30, 2021 11:21 am
a small update:
i am now at the step where i am able to fill a 4 voices dma buffer, with 4 samples and volume for each voice, in 1 pass
it takes 7,7% of the cpu time @ 20833,33 khz ( 12 mhz cpu)

the mixing code uses all registers, and have all 4 volumes in 1 , using lsr/lsl, and the incremented byte sources are offsets related to the beginning of the sample. This way i don't have 1 register per instrument, but 1 register for the base address of the samples.
Oh excellent, so you end up with 4 bytes in one register and use a single word-store? I did this in "QTMTurbo", back in the early 90s, in fact I think I managed to fill 8 bytes at a time (storing 2 words using STMIA), I used the FIQ register bank and fully unrolled code for maximum efficiency (unrolled really boosted performance). I recall the biggest challenge was to get looping samples handled perfectly in unrolled code (needed the extra registers of FIQ).

Sadly QTMTurbo didn't get widely released or used, because the use of FIQ stopped users running the floppy drive... And ARM3 came along and made all that unrolled code redundant.
ericde45 wrote:
Wed Jun 30, 2021 11:21 am
not sure i will keep running it @ 20,8KHZ as Amiga's samples from the old times are at maximum 15 khz. most of the samples were around 8-11 khz.
Are you writing a tracker (playing samples at different pitches) or just playing fixed rate samples?

If varying the pitch, reducing below 20.8kHz will sound awful for users that have removed their sound filter. This is because unlike the Amiga (which has separate sound frequency registers for each of the 4 channels) the varying pitch of a sample on the VIDC (one frequency setting) is created in software by either repeating or skipping sample bytes as it fills the buffer in order to adjust the pitch. So on the Archie you ideally need to select twice the sound frequency of the highest pitch sample played, to avoid noticeable aliasing effects of the sound filter is removed. QTM uses 31.25kHz as default to get best output quality on unfiltered systems for most samples used back in the day.
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

yes, the mixing rout ends with a nice str R7,[R14],#4
that was my aim for mixing 4 voices
lrdb and strb are really slow ( compared to the general speed of the ARM of course )

i thought i might unroll , and it is so easy with vasm, you just put a .rept 416 / code / .endr and you have 416 times the same part of code :)
( Devpac was doing this on ST also, in the old days )

FIQ registers is an interresting and clever idea :) i will think about it later, as i only mix 4 voices, this might be faster.

i don't undestand the issue with quality.
yes i use one increment with pseudo-coma on 12 bits, for each voice.
so i have 4 frequencies to read the samples, i don't get the difference with the Amiga
but aliasing of sound is far above my knowledge on sound theory :)
sirbod
Posts: 1228
Joined: Mon Apr 09, 2012 9:44 am
Location: Essex
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by sirbod »

There was a commercial tracker that used FIQ registers, I don’t recall which one off-hand but I do remember having to completely rewrite its fill code to get it working correctly.

Unless you’re targeting a very specific machine, I’d urge avoiding the use of FIQ and unrolled loops, or at least provide two builds for ARM2 and ARM3+ as unrolled is really inefficient beyond the first ARM core.
User avatar
SarahWalker
Posts: 1404
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by SarahWalker »

The S3M player in Horizon was fully unrolled, supporting looping samples correctly without the need for FIQ registers. Not sure what you'd need them for to be honest? I did end up needing to use r13 as a temporary register though, so the buffer fill routine ran with interrupts disabled which was pretty horrible. That's probably worse to be honest.
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

sirbod wrote:
Thu Jul 01, 2021 6:48 am
There was a commercial tracker that used FIQ registers, I don’t recall which one off-hand but I do remember having to completely rewrite its fill code to get it working correctly.
Oh which was that? and did it do the same idea to calculate four channel's worth of data at once, then store in a single STR?
SarahWalker wrote:
Thu Jul 01, 2021 8:10 am
Not sure what you'd need them for to be honest?
Only in the pursuit of ultimate optimisation by using the extra registers to enable 4 channels at a time to be calculated and filled as words with STR or STMIA, removing need for muliple STRBs. :)

QTMTurbo did this as a proof of concept and gave a measurable boost under certain circumstances ie. all channels playing at once, at mixed volumes, and it gave consistent CPU usage (which may be a benefit for some demo timing). However for me there were too many compromises - complex bulky code, unable to use with floppy drive, and it actually gave higher CPU usage (vs. original QTM) in cases such as where only 1 or 2 channels were active/playing. The original QTM DMA buffer fill is optimised on an individual channel basis and uses different code paths to avoid filling blank channels, not applying volume scaling if the channel volume is full, not checking for end of sample/loops if the sample won't end during the current buffer fill, etc. which was better overall for most users and works with all RISC OS versions.
User avatar
SarahWalker
Posts: 1404
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by SarahWalker »

not checking for end of sample/loops if the sample won't end during the current buffer fill, etc
I didn't realise QTM was checking for end of sample during the fill. My player simply added 512 bytes at the end of each sample (copied from loop start for looping samples, zeroes for non-looping samples) and performs the check at the end.
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

SarahWalker wrote:
Thu Jul 01, 2021 12:06 pm
not checking for end of sample/loops if the sample won't end during the current buffer fill, etc
I didn't realise QTM was checking for end of sample during the fill. My player simply added 512 bytes at the end of each sample (copied from loop start for looping samples, zeroes for non-looping samples) and performs the check at the end.
It's a couple of simple additions and shifts per channel to tell if the sample is ending or looping during an upcoming fill. If it isn't (which is most of the time, for most samples), then QTM uses fill code that doesn't check for a loop/end.

The approach you've taken, to add an end of sample/loop buffer to each sample, would have been perfect for the QTMTurbo proof of concept (and probably would be ideal for Eric's approach above). This is also a great optimisation for really small looping "chip" samples that loop every buffer fill, and would always trigger the "sample looping" check above.
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

yes, that's also what i do, what i am currently coding, adding space between each sample, to avoid testing the end of the sample during mixing.
( i already did that on Atari ST )
sirbod
Posts: 1228
Joined: Mon Apr 09, 2012 9:44 am
Location: Essex
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by sirbod »

steve3000 wrote:
Thu Jul 01, 2021 11:50 am
Oh which was that? and did it do the same idea to calculate four channel's worth of data at once, then store in a single STR?
I honestly don’t remember, sorry.

I don’t think I’ve come across any players that use STR, not that I remember at any rate.
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

today's state of my player : https://youtu.be/kD7I_S8WHCk

all knowledge acquired comes from QTM and Steve :)
+ LSP player from Arnaud Carré converted to ARM

CPU time at 20833 khz is 8 to 10% @ 12mhz

a good start to have music in demos.
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

Great work, it sounds good! And nice to see a new mod player on the Archie, it's been a while.

How are you working out your CPU usage? Are you counting scanlines (wait until top of screen, set colour, call music code and DMA code, clear colour)? I did this for the RasterMan version of QTM a few years ago...must dig out that code...
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

there are still some bugs to be hunted. i can hear them with some modules :)
( i set up an Amiga emulator to test the original LSP code in case bugs were coming from the original source, but no...)

to count cpu time, i made a small loop to go pass end of screen and once at start of screen i change the background color directly in the registers, i run my player + my mixing code, and switch back to black. i take a screen shot of Arculator, and i count the lines in GIMP :)
User avatar
ericde45
Posts: 80
Joined: Sat Feb 13, 2021 12:49 pm
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by ericde45 »

there are still some bugs to be hunted. i can hear them with some modules :)
( i set up an Amiga emulator to test the original LSP code in case bugs were coming from the original source, but no...)

to count cpu time, i made a small loop to go pass end of screen and once at start of screen i change the background color directly in the registers, i run my player + my mixing code, and switch back to black. i take a screen shot of Arculator, and i count the lines in GIMP :)



---------------- update :

as i have a quality issue with my player, i tried to go back to the start
i just coded a small program that play a sample
the sample is fine on PC @ 8000 Hz
but once converted to mu-law Archimedes expected values, i have some noise

the end of the sample features silence. values in the 8-bits signed sample are either 00, or 01 or $FF
these values converts ( at volume=64) to :

linear signed to mu law
00 => 00
01 => 00
FF (-1) => 01

that seems logical

but if i fill a sound buffer with values :

00020002 : this is nearly silent, a low volume high-pitched sound
00010001 : a higher volume high-pitched sound

sample with the bit 0 =1 are louder than sample with bit 0=0

and i have the feeling that this give me noise at the end when playing the sample

any idea ?
steve3000
Posts: 2493
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: QTM (QTheMusic) v1.45 released

Post by steve3000 »

ericde45 wrote:
Sat Jul 10, 2021 1:07 pm
linear signed to mu law
00 => 00
01 => 00
FF (-1) => 01

that seems logical
It may seem logical, but your assumption is incorrect. 8-bit linear -1 does not map to +1 in VIDC 8-bit log format.

The value +1 in VIDC log actually causes problems - it certainly is not the equivalent of linear -1, rather the equivalent of "-0", because you're effectively setting the sign bit without selecting a chord or point value (see the VIDC approximation of mu-law in the VSLI ARM databook on page 5-18) - and the VIDC doesn't like this.

How are you converting from 8-bit linear to VIDC log? I've cut/paste the following from notes I made on 8-bit linear to VIDC log conversion, some time ago. May be useful here :)

You may have read the VIDC 8-bit log implementation gives an equivalent dynamic range to 13-bit linear, at the expense of some (near-inaudible) linear resolution. However this means that when converting a linear 8-bit sample to VIDC 8-bit log, the mapping is not 1:1.

You can easily produce a table of 13-bit linear values corresponding to VIDC 8-bit log using the BASIC code below:

Code: Select all

FOR sign=0 TO 1
 linear13bit=0
 FOR chord=0 TO 7
  linearstep=2^chord
  IF sign=1 THEN linearstep=0-linearstep
  FOR point=0 TO 15
   logbyte=(chord<<5)+(point<<1)+sign
   IF logbyte=1 THEN logbyte=0
   PRINT"13-bit linear value ";linear13bit;" = 8-bit log value ";logbyte
   linear13bit=linear13bit+linearstep
  NEXT
 NEXT
NEXT
So when converting 8-bit linear to VIDC 8-bit log you really need to scale your 8-bit linear up to 13-bit linear, to use the full dynamic range of VIDC 8-bit log (by shifting the 8-bit linear value left 5 places, or multiplying by 32). When you do this, you'll see that 8-bit linear value of 1 becomes 13-bit linear value or 32 and -1 becomes -32. Then using the above conversion code, a 13-bit linear value of 32 in maps to a VIDC 8-bit log value of 48, and -32 maps to 49.

Once this is clear, then you find the easiest way to build a 8-bit linear to VIDC 8-bit log conversion table is to use RISC OS's built in conversion code to build the table for you:

Code: Select all

FOR linear8bit=0 TO 255
 SYS "Sound_SoundLog",linear8bit<<24 TO logbyte
 PRINT"8-bit linear value ";linear8bit;" = 8-bit log value ";logbyte
NEXT
So back to your problem:
+1 in 8-bit linear actually maps to +48 in VIDC 8-bit log
and
-1 in 8-bit linear actually maps to +49 in VIDC 8-bit log

...and avoid sending the value +1 to VIDC at all costs, because it causes a "pop". :shock:
Post Reply

Return to “32-bit acorn software: other”