Search the Community
Showing results for tags 'imt'.
Found 2 results
I am considering adding a glissando or portamento effect to the Intellivision Music Tracker, and I would like to know how this sort of thing has been implemented in other trackers. Can anybody provide any details on how it works in any other tool they've used in the past? Any guidance or suggestions would be greatly appreciated. -dZ.
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: 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. 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. 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.