Jump to content
IGNORED

How to handle long notes with fast envelopes?


DZ-Jay

Recommended Posts

Reviving this old question about how to handle very long notes with fast envelopes in the Intellivision Music Tracker.  To recap, the problem is that the tracker has no bounds checking in its envelopes, so if a note extends for too long, the envelope pointer will overflow to somewhere else in the data, which is most likely another envelope or trash.  This is even more pronounced after I added very fast envelopes in the last tracker revision, which advance on every tick.

 

I would appreciate if anybody has any suggestions on how best to resolve this issue.  The problem can be split into two parts:

  • First, there's the design component:  how should the tracker handle very long notes?  Should envelopes loop, backtrack, or just end?
  • Second, there's the technical component:  how to make this work within the constraints of the current implementation.

 

For the first part, I can think of three possible solutions:

  1. Envelopes that include a backtracking offset, as suggested by @carlsson in the past.  The idea is that when the synthesizer reaches the end of the envelope, it will use this offset to backtrack and repeat.  This would allow for more flexible instrument design, but it may be over-complicate the implementation.  It may also break previous songs.
  2. Envelopes that recycle automatically to a set point.  This is what IntyBASIC currently does, which seems in tune with how real instruments work:  once an amplitude level is reached, it is sustained until the note is released.  This would be a bit less flexible than allowing arbitrary backtracking, but seems that it should be easier to implement.  It would also be fully-backwards compatible with existing songs.
  3. Require very long envelopes, say 128 sample points instead the current 64.  The problem is that envelopes require one data word per each sample point, so an extra 64 points will require 16 additional data words, per envelope.  With lots of envelopes in use, this can get costly fast.

 

I think #3 is not really an option.  It is actually the way it works today (since the 64-point length is not enforced), but it leads to bloat.  Plus, there is never a guarantee that a long enough note will not overflow the envelope.  My experience suggests that this sort of problem is hard to identify.

 

I think #1 is a good thing to have, but perhaps arbitrary offsets are not strictly necessary, and perhaps not worth the processing cost.  After all, IntyBASIC proves that a static backtracking offset is perfectly adequate.  Plus it sort of mimics the typical ADSR (Attack/Decay/Sustain/Release) envelope scheme, where the "Sustain" amplitude is maintained indefinitely until release.

 

What do you think?  Any feedback is welcome.

 

     -dZ.

Link to comment
Share on other sites

I'm probably good with #2, which as you mention is the easiest solution. Solution #1 though would allow for e.g. volume vibratos, wah-wah, sirens, hairpins (like I used for several of the arpeggios in the Voyage songs) and all kinds of odd shapes. If the song format is changed, I would imagine the pool of known songs is small enough to have everyone who are agile and talented enough to use the tracker, be able to update their songs. Perhaps there could even be a tool that converts songs from tracker version X.XX to version X.YY, depending on if additional changes to the format would be implemented at the same time.

Link to comment
Share on other sites

As for the implementation part, consider how the envelopes currently work:

  • There is an 8-bit counter per channel that goes from 0 to 255, and is used to synchronize all effects on a note (envelope, arpeggio, vibrato, etc.).
  • The counter starts at zero when a note starts, and increments until the next note, or the channel is silenced.
  • The counter is adjusted depending on the speed of the envelope, each slower speed dividing the counter by 2.
  • After adjusting the counter, the result is used as an index into the envelope table, which is packed 4-points per DECLE, one on each 4-bit nybble.
  • After retrieving the appropriate word from the envelope table, the target nybble within the DECLE is computed as "Counter modulo 4."

Note that a problem is is that the counter is for the entire instrument, not just the envelope.  Therefore, we cannot just adjust it and save it; we have to account for an ever increasing counter.

 

For instance, if I want to set a static backtrack offset of 8 (like IntyBASIC), I need to subtract 8 plus whatever overflow there is.  This is the quick-and-dirty patch I came up with:

	; Check envelope counter
	; ----------------------
	; R0: Counter
	; R1: Free
	CMPI    #64,    R0      ; Has the counter gone over?
	BLT     @@env           ; If not, process envelope normally

	MOVR    R0,     R1      ; \
	ANDI    #$3F,   R1      ;  > offset = (counter & 63) + 8
	ADDI    #8,     R1      ; /
	SUBR    R1,     R0      ; counter -= offset

	; Process envelope
	; ----------------------
@@env

 

That was just quick-and-dirty.  Any ideas for improvement are welcome!

 

     -dZ.

Link to comment
Share on other sites

2 minutes ago, carlsson said:

I'm probably good with #2, which as you mention is the easiest solution. Solution #1 though would allow for e.g. volume vibratos, wah-wah, sirens, hairpins (like I used for several of the arpeggios in the Voyage songs) and all kinds of odd shapes. If the song format is changed, I would imagine the pool of known songs is small enough to have everyone who are agile and talented enough to use the tracker, be able to update their songs.

 

Yes, I agree.  I would love to implement #2, but I think I rather do it in a more holistic way than just hack the code right now to fix this immediate problem.  My main concern is not only backwards-compatibility (like you said, there aren't that many songs out already, so it's not a big deal).  My main concern is the cost in processing to handle it.

 

I can work on that as a future enhancement with other features, like you have suggested.

 

2 minutes ago, carlsson said:

Perhaps there could even be a tool that converts songs from tracker version X.XX to version X.YY, depending on if additional changes to the format would be implemented at the same time.

 

That's an idea.

Link to comment
Share on other sites

2 hours ago, carlsson said:

I'm probably good with #2, which as you mention is the easiest solution. Solution #1 though would allow for e.g. volume vibratos, wah-wah, sirens, hairpins (like I used for several of the arpeggios in the Voyage songs) and all kinds of odd shapes. If the song format is changed, I would imagine the pool of known songs is small enough to have everyone who are agile and talented enough to use the tracker, be able to update their songs. Perhaps there could even be a tool that converts songs from tracker version X.XX to version X.YY, depending on if additional changes to the format would be implemented at the same time.

@carlsson, I have a compromise for you:  the backtracking offset is configurable globally.  This won't give you the flexibility per instrument, as in #1, but it allows you to configure it per program, via a global constant.

 

Plus, since it is subtracted from the end, it can be any value from 0 to 63.  Not bad for a quick-and-dirty patch. :)

 

     -dZ.

  • Like 1
Link to comment
Share on other sites

I managed to make a few micro-optimizations (both in size and speed) to compensate for the additional tests added in the last couple of enhancements.  Yay!

 

I'm preparing a new revision release for next week to include the optimizations and the new envelope backtracking.  As long as I'm mucking about in there, if anybody has any particular enhancements they want to see, just post them here.  I can't promise it'll be included this time, but I can at least consider it and add it to my TO-DO list. :)

 

     -dZ.

  • Like 1
Link to comment
Share on other sites

Any thoughts or comments on this topic?  Anyone?  ... Bueller?

 

I expect to release the new version (revision #4) this week-end.  There's still time to cram more stuff in it! :)

 

    -dZ.

Link to comment
Share on other sites

  • 2 weeks later...

For anybody still paying attention, the solution for looping envelopes is fully described in the User Manual & Technical Guide, available from the dedicated thread of the Intellivision Music Tracker.

 

I reproduce the section below, for reference:

 

 

Cycling Envelopes

When the end of an envelope is reached while a note is still playing, the envelope is recycled by backtracking eight sample steps from the end, and looping over them. Thus, notes can continue playing for very long durations, repeating the amplitude pattern at the end of the contour. This feature is of particular value for emulating real-life instruments with typically long, sustained notes, such as certain wind and string instruments.

 

Consider for example the graph below, which illustrates a simulation of a woodwind instrument, such as a flute, or an oboe. As shown, the envelope has a slow attack phase, then decays gradually, until it reaches a moderate sustained level.

 

However, instead of dropping off completely, the contour emulates the subtle tremolo effect characteristically of long notes in such instruments, by wavering its amplitude rapidly at the tail end.

 

image.thumb.png.d15301c3169dab92e68137d0c32da9df.png

 

If the note is sustained for very long, enough to overrun the length of the envelope, the instrument synthesizer will automatically backtrack and loop through the last eight samples, repeating them for as long as the note endures. By accounting for this feature in the envelope design, the transition can be made to appear seamless.


The end result is a rather close approximation of the pleasant characteristic sound of the original natural instrument.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...