Instrument sequence timing and other changes

Post about feature requests here.
Baka94
Posts: 54
Joined: Fri May 15, 2015 5:15 pm

Instrument sequence timing and other changes

Postby Baka94 » Mon Jan 11, 2016 8:55 am

Right now the sequence goes one value per "tick", but sometimes it's difficult to time some effects, like arps to match the tempo of the song. That's why I wanted to request a possibility to change the update freqency of the sequence. Some selections would be:
-Tick: the default selection and setting FamiTracker uses now
-Row: updated once per row; tempo affects this
-Custom: opens a field where you can write the update algorithm. Writing "row/3" or "row/6" would make a triplet timing. Letters A-F could be used as arguments that can be modified with a pattern effect.
Example: Mxy (M can be replaced with another letter if it's already used)
x = Argument to modify in currently active instrument
y = New value of the argument
These arguments could be used in other sequences to do things like modify arp sequence between major and minor chord:
| 0 (3+B) 7 12

B = 0; minor chord
B = 1; major chord

Another suggestion I have is allowing you to use apprpeggio sequence to change DPCM sample and pitch sequence to change sample pitch.
The last suggestion is the ability to combine a, r and f letters (absolute, relative and fixed) in pitch sequence values similarly how you combine tone and noise modes in the Sunsoft 5B chip. This would allow you to override (?) the default mode set from the drop down menu.

User avatar
w7n
Posts: 241
Joined: Fri May 15, 2015 1:37 am
Location: Nanamori-Chuu
Contact:

Re: Instrument sequence timing and other changes

Postby w7n » Mon Jan 11, 2016 10:00 am

the 3+b thing is exactly the arp scheme in 0cc.
your timing suggestion might be good, but i am rather concerned about it further increasing the ft nsf engine's burden (which is already very inefficient)
nsf.nesbbs.com under reconstruction, better player might be available in the future.

VRC6 PWM is GAY because it has colours of the rainbow in the NSFPlay keyboard visualizer.

Baka94
Posts: 54
Joined: Fri May 15, 2015 5:15 pm

Re: Instrument sequence timing and other changes

Postby Baka94 » Mon Jan 11, 2016 10:43 am

w7n wrote:the 3+b thing is exactly the arp scheme in 0cc.


The only problem with the 0xy effect is you can't change the speed of the arp. You can only specify the notes in the arp, which is already very limited. This would allow you to change the arp without creating multiple instruments. Another option would be the ability to change a single sequence in the instrument with a pattern effect.

User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: Instrument sequence timing and other changes

Postby HertzDevil » Mon Jan 11, 2016 10:48 am

Baka94 wrote:-Row: updated once per row; tempo affects this
-Custom: opens a field where you can write the update algorithm. Writing "row/3" or "row/6" would make a triplet timing. Letters A-F could be used as arguments that can be modified with a pattern effect.

Are you the same person who made that misaligned triplet pattern editor row mockup with a Txx effect at the old forum?

Neither the tracker nor the NSF driver has perfect information of the number of ticks at any given row. (Possibly irrelevant.) It is possible to create a specialized sequence collection that cycles through each contained sequence every time a new note is triggered, similar but not identical to LSDj's automate table, or XPMCK's (EVERY-NOTE) callback, but these kind of instruments should have been a different instrument type anyway, rather than augmenting the existing type. Sub-row time resolutions are most likely not going to happen as they require more overhaul in the player engine than they are worth.

If for some reason your patterns keep doing stuff at exactly one or two thirds the duration of a row, you should triple your BPM.

Baka94 wrote:The only problem with the 0xy effect is you can't change the speed of the arp. You can only specify the notes in the arp, which is already very limited.

If an instrument uses a (looped) arpeggio sequence, the 0xy is not going to affect the instrument anyway. There is also no need to specify a separate "Mxy" effect; if you absolutely need different semitone parameters as an arpeggio sequence finishes, just place another 0xy effect, which has no side effects. (0xy does not reset the arpeggio phase, triggering new notes does.)

Baka94 wrote:This would allow you to change the arp without creating multiple instruments.

Done that already, and that was before 0CC-FamiTracker was created. I have used { | 0 x+12 y 12 x y+12 } for more than a year, and also seventh chords via { | 0 0 y y x x 10 10 }.

Baka94 wrote:Another option would be the ability to change a single sequence in the instrument with a pattern effect.

One should not create such effect for only a single sequence type, so either five effects would be required, or the parameter could be overloaded to select the sequence type, e.g. ?00 - ?7F replaces the sequence, the special ?FF halts the sequence, and ?FA-?FE select the sequence type (it requires that instruments have 5 sequences at most, but should that be extended jsr can simply update the PATTERNS block version and replace all existing effects). Remember, however, that exported NSFs have no concept of sequence index right now, so I do not know how much effort is needed at this moment to include such an effect.

The last suggestion is the ability to combine a, r and f letters (absolute, relative and fixed) in pitch sequence values similarly how you combine tone and noise modes in the Sunsoft 5B chip. This would allow you to override (?) the default mode set from the drop down menu.

5B does not because the noise frequency (5 bits) plus the output toggle flags (3 bits in 0CC-FT, 2 in official) fit into one byte, but this feature requires two bytes per sequence term instead of one. Performance is not exactly a problem, FamiTracker has never intended its NSFs for compact use, jsr himself has also suggested Famitone2 where performance comes into play; but this would break compatiblity with other sequence types, since a subclass or a superclass plus sibling of CSequence would be needed, and the NSF driver might need special handling for that particular sequence type. How would you resolve the note value exactly when these arpeggio modes mix?
refactoring 0cc-famitracker

User avatar
Stratelier
Posts: 378
Joined: Sun Apr 26, 2015 7:46 pm

Re: Instrument sequence timing and other changes

Postby Stratelier » Mon Jan 11, 2016 2:10 pm

HertzDevil wrote:If for some reason your patterns keep doing stuff at exactly one or two thirds the duration of a row, you should triple your BPM.

Yeah, if it sounds like a song uses triplets exclusively (at the expense of ordinary divisions), then you don't have a triplet problem you have a meter problem (e.g. 6:8 time not 4:4). Set the Row 1 highlight to your desired # divisions per beat, row 2 highlight and frame length some multiple of that. The statusbar will calculate the effective BPM taking the meter (row 1 highlight) into account.

Baka94 wrote:The only problem with the 0xy effect is you can't change the speed of the arp. You can only specify the notes in the arp, which is already very limited.

I wouldn't mind seeing some kind of generic "parameter overload" effect that allows you to specify more than one byte of data for the effect immediately to its left. For the arp effect it could specify, say, arp timing (ticks per semitone) and starting tone (people have expressed desire for starting an arp on its semitones). Of course that would make the effect design (in terms of NSF code) a bit more complicated....

User avatar
HertzDevil
Posts: 475
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: Instrument sequence timing and other changes

Postby HertzDevil » Mon Jan 11, 2016 2:16 pm

To be honest, just create a separate effect for that purpose if you must. There is almost no advantage in making effect commands variadic on the NSF driver side (and we are not running out of effect command indices either).
refactoring 0cc-famitracker


Return to “Feature Requests”

Who is online

Users browsing this forum: No registered users and 1 guest