This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

21

Players / Question about Volume Slide (Axy)

« on: February 27, 2024, 20:00:05 »

Hello,

Yes, I am still working on my project.  I had some major set-backs (more than before), and have to come up with a brand now way to encode the data.  That lead to a re-writing of the music player, instrument synthesizer, and the effect handlers.

The good news is that I've been looking at a C port of the FT2 source code to guide my understanding of the effects in the original XM implementation.  This has been very helpful indeed, and I have managed to implement (correctly) Portamento Up/Down, Note Portamento, Arpeggio, Vibrato, and I'm in the process of completing Volume Slide.

I do have one question on the Volume Slide (Axy) effect.  Suppose I have an instrument volume envelope enabled, does the Volume Slide effect respect it, or does it actually adjust the absolute volume of the note?

Let me give you an example.  If someone sets a volume slide to go up, and lets it go up all the way to maximum volume, does the note continue playing at maximum volume even if the envelope is in decay?

If I am reading the source code of FT2 correctly, it seems that the Volume Slide effect ignores any modulation on the volume of the note, and produces an output based on the "real" volume of the note (the one in the pattern data) modified by the slide.

I hope this question makes sense.

     -dZ.

22

Players / Re: Understanding effects processing

« on: January 21, 2024, 18:24:22 »

Quick update:  Vibrato is done! (That was quick!  )

Attached is a test sample extracted from the emulator.  It uses the following pattern -- a single note played for 32 rows, with a flat sustain instrument envelope, just to let the vibrato play out:

Code: [Select]

00 C-4 -3 F 444 ; Speed: 4; Depth: 1/4
01 --- -- - 400
02 --- -- - 400
03 --- -- - 400
04 --- -- - 400
05 --- -- - 400
06 --- -- - 400
07 --- -- - 400
08 --- -- - 480 ; Speed: 8
09 --- -- - 400
10 --- -- - 400
11 --- -- - 400
12 --- -- - 400
13 --- -- - 400
14 --- -- - 400
15 --- -- - 400

16 --- -- - 408 ; Depth: 1/2
17 --- -- - 400
18 --- -- - 400
19 --- -- - 400
20 --- -- - 400
21 --- -- - 400
22 --- -- - 400
23 --- -- - 400
24 --- -- - 40F ; Depth: full
25 --- -- - 400
26 --- -- - 400
27 --- -- - 400
28 --- -- - 400
29 --- -- - 400
30 --- -- - 400
31 --- -- - 400

I've adapted the effect to conform to the platform capabilities.  It simulates an LFO with a sine waveform plotted over 64 points, with a maximum amplitude of +/- 2 semitones:

Code: [Select]

      0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
30 0F :.............#####.............:...............:...............
29 0E :...........##..:..##...........:...............:...............
28 0D :..........#....:....#..........:...............:...............
27 0C :........##.....:.....##........:...............:...............
26 0B :.......#.......:.......#.......:...............:...............
25 0A :......#........:........#......:...............:...............
24 09 :...............:...............:...............:...............
23 08 :.....#.........:.........#.....:...............:...............
22 07 :....#..........:..........#....:...............:...............
21 06 :...#...........:...........#...:...............:...............
20 05 :...............:...............:...............:...............
19 04 :..#............:............#..:...............:...............
18 03 :.#.............:.............#.:...............:...............
17 02 :...............:...............:...............:...............
16 01 :#..............:..............#:...............:...............
15 00 #---------------+---------------#-------------------------------
14 01 :...............:...............:#..............:..............#
13 02 :...............:...............:...............:...............
12 03 :...............:...............:.#.............:.............#.
11 04 :...............:...............:..#............:............#..
10 05 :...............:...............:...............:...............
09 06 :...............:...............:...#...........:...........#...
08 07 :...............:...............:....#..........:..........#....
07 08 :...............:...............:.....#.........:.........#.....
06 09 :...............:...............:...............:...............
05 0A :...............:...............:......#........:........#......
04 0B :...............:...............:.......#.......:.......#.......
03 0C :...............:...............:........##.....:.....##........
02 0D :...............:...............:..........#....:....#..........
01 0E :...............:...............:...........##..:..##...........
00 0F :...............:...............:.............#####.............

The speed parameter is obviously how many points in the graph to advance on each tick, and the depth parameter scales the amplitude at each point in 1/16^th increments.  So, a depth of $4 will be 4/16^th of the amplitude at the current point in the graph, and a depth of $F will be 16/16^th, or the full amplitude.

The only thing I am not really sure about is the maximum amplitude of the LFO.  I have it right now to be the distance between the previous and the next semitone of the active note -- or +/- 2 semitones.  I think this is how it should be.

Any feedback is appreciated!

     -dZ.

23

Players / Re: Understanding effects processing

« on: January 20, 2024, 16:16:41 »

Just a minor update -- I'm still working on this project, I just ran out of Christmas vacation days so I have mostly the week-ends to work on it.

I had a rather major set-back due to the way I implemented the pitch bending effects -- when the effect runs out, the original tone was being reset, which is not correct.  It wasn't really a bug, more like a design flaw.  This was particularly bad in the Note Portamento:  if the effect ran out before reaching the new note, the period would be reset to the new note anyway!

In any case -- I came up with a different approach, and now I am happy to say that I have finally slay that dragon for good!  Portamento Up/Down and Note Portamento behave correctly. 

Now, on to Vibrato.  It's going to be tricky because my target CPU (GI CP-1610) does not have instructions for multiplication or division -- heck, it doesn't even have a logical OR instruction! -- so scaling amplitudes and tone periods is expensive.

Nevertheless, I think I see a way out ... stay tuned!

     -dZ.

24

Players / Re: Understanding effects processing

« on: January 09, 2024, 13:30:39 »

I have another question:  For vibrato effect, what does the "y" parameter represent?  Is it just a period or is it an index into some table of offsets?

I found some information here:
https://forum.openmpt.org/index.php?topic=6835.0

The pattern effect (4xy) has a resolution of 1/8th of a semitone in linear slides mode, so at the maximum depth (15) it spans approximately +/-2 semitones.

Seems reasonable.  Now I have to figure out how to modulate that with the various waveforms.  My tracker uses a static triangle waveform for instrument auto-vibrato (a simple linear ramp up and down dividing the peak amplitude by powers of 2), so I can't re-use that one.

I suppose I could limit my implementation to a single waveform.  If so, which would you recommend?  Triangle is linear and straightforward, but sine is the XM default ... Any suggestions?

     -dZ.

25

Players / Re: Understanding effects processing

« on: January 08, 2024, 22:29:13 »

I have another question:  For vibrato effect, what does the "y" parameter represent?  Is it just a period or is it an index into some table of offsets?

I know that the speed is how much to advance the position in the waveform on each tick (like I do with volume envelopes), but I'm not sure I know what to do with the depth parameter.

    -dZ.

26

Players / Re: Understanding effects processing

« on: January 08, 2024, 21:07:04 »

Got something ...   

I made a quick and dirty test with the following pattern.  See the attached output from the emulator.

Code: [Select]

00 C-4 -3 F 210
01 --- -- - 200
02 --- -- - 208
03 --- -- - 200
04 --- -- - 204
05 --- -- - 200
06 --- -- - ---
07 --- -- - ---
08 --- -- - ---
09 --- -- - ---
10 --- -- - ---
11 --- -- - ---
12 --- -- - ---
13 --- -- - ---
14 --- -- - ---
15 --- -- - ---

16 C-3 -- F 110
17 --- -- - 100
18 --- -- - 108
19 --- -- - 100
20 --- -- - 104
21 --- -- - 100
22 --- -- - ---
23 --- -- - ---
24 --- -- - ---
25 --- -- - ---
26 --- -- - ---
27 --- -- - ---
28 --- -- - ---
29 --- -- - ---
30 --- -- - ---
31 --- -- - ---

I am now tracking the pitch delta separately and applying it the the note period for as long as the note lasts.  Portamento increments or decrements this value, depending on the case.

When the effect stops (rows #06 and #22), the delta continues being applied to the note.  On a new note, the delta is reset.

I suppose I can also use this same state variable for the "Set Fine-Tune" effect (E5x) later on.

     -dZ.

27

Players / Re: Understanding effects processing

« on: January 08, 2024, 18:30:48 »

Er ... I just took a long hot shower (what I tend to do to think and ponder) and had an epiphany -- I think I may be able to fix my pitch bending behaviour.   

Stay tuned!

    -dZ.

28

Players / Re: Understanding effects processing

« on: January 08, 2024, 17:46:02 »

Call it a technical limitation of the way it was originally implemented.  It means that the moment you stop a portamento effect, the note will go back to its base pitch.  I don't see a way around it at the moment without re-writing the entire thing.  :'(

This might help:
The way portamento and vibrato works in a tracker is by changing the speed of the sample played. so to tone down the note's pitch, the sample is gradually slowed down.

I should have also mentioned, but pitches in trackers work same way any sampler does in a DAW. You tune it to a specific note and then each note corresponds to a certain speed stretch of the sample.

It doesn't work that way on non-sample based trackers of course, but if you're aiming to port XM, you should keep that in mind, maybe that helps you solving the question

Thanks.  The problem I have is that my tracker was never intended to replicate XM.  The individual who originally developed it, based it on XM -- but stripped it to its minimum in order to fit within the platform constraints and be super fast and compact to include in our games.

I have since carried on the mantle of maintaining it, and now I'm sort of stretching its capabilities by adding support for (some) XM effects.  However, I don't think I will ever be able to achieve parity -- the Intellivision is really a rather limited platform, and my tracker has carried on certain original design choices that limit its flexibility.

For instance, consider that the tracker runs on a three step cycle:

• Music Player - Counts rows, keeps track of pattern position, etc.
• Instrument Synthesizer - Runs per tick, plays note, applies envelope, etc.
• Generate tones - Post the period and volume output of the synthesizer, to the sound processor.

Step #2 is very simplistic:  For each channel, it keeps track of the current note, instrument, and volume.  It has a counter that it uses to advance the state of envelope (and now effects).

On every tick it does the following:

• Look up note period in table.
• Apply instrument vibrato (using lookup table)
• Apply instrument envelope (using envelope table)
• Modulate volume based on note
• Finally, update period and volume registers in sound device.

As you can see, it is sort of "stateless":  the period and volume are re-computed on every tick based on the current note and instrument -- and the channel counter is used to know how much to modulate by as it progresses.

I've added a new stage between #2 and #3 to apply effects.  Once the instrument synthesizer computes the period and volume for the current tick, an active effect will further modulate them.

It works, but the downside is that the moment the effect stops modulating, the instrument synthesizer will compute the pitch and volume as normal, so the note will sound exactly as it would at that point in the pattern, had the effect not being applied.

Obviously this is not compatible with XM and other trackers.  But re-engineering that is akin to starting the tracker from scratch, which seems a lot more daunting than what I'm actually doing.

I hope this makes sense.  Anway, sorry for the long post.

    -dZ.

29

Players / Re: Tempo, Speed, Rows, etc.

« on: January 08, 2024, 17:10:24 »

Intuitively (and naïvely), I feel that you either measure your track tempo by Ticks-Per-Row (Speed), or by Beats-Per-Minute (BPM), but not both.  To me, the former seems more natural in a tracker; while the latter is more natural in a higher-level production software, like Logic, etc.

I don't think that's the case for trackers here, because I've seen modules both with custom TPR and BPM together.

Yes, I've seen that too.  That's what prompted my question -- it is the source of my confusion.  I must be misunderstanding something because in my mental model, they are separate measurements.

As I see it, when using BPM, you would have to necessarily define how many rows fit in a "beat."  But then, there is nowhere to enter such a number in trackers, so it seems very arbitrary to me.  (I guess you can just keep it in your head, like a 4/4 signature = 4 rows per beat, 16 rows per pattern, etc.)

There is a setting for XM to specify the number of rows on a pattern

That is true, but nothing tells you that a pattern is one beat -- or does it?

From what I see, if I set a pattern to 16 rows, nothing tells me how many "beats" those are -- it could be one beat, or four beats, eight beats, 16, or whatever.  In fact, I believe you can have patterns of different lengths in the same song, yet only one BPM at any point in time.

Anyway, I'll continue ignoring this aspect of trackers for now -- at least while I focus on effects.  For the time being my tracker uses only the ticks-per-row "speed" parameter.

Thanks
    -dZ.

30

Players / Re: Understanding effects processing

« on: January 08, 2024, 17:01:15 »

Correct. the base volume of the instrument/sample isn't affected by the commands, but are instead affected on the channel where its played on. Let's just say, that whatever happens on the pattern sheet stays within that pattern sheet :-)

That makes sense, and I just observed that same behaviour in MilkyTracker.

I may be able to replicate that behaviour for volume, but unfortunately not for pitch-bending.

Call it a technical limitation of the way it was originally implemented.  It means that the moment you stop a portamento effect, the note will go back to its base pitch.  I don't see a way around it at the moment without re-writing the entire thing.  :'(

     -dZ.