Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
Everybody uses arpeggio tables. This command could reference an arpeggio table as the notes to play in sequence.
Let's say arp table 0 is "0 4 7 |". If a table is referenced it could do the arping for us. However the loop and hold points will be ignored.
Here are some useful features that I had in mind and how it should operate. First off, I do not believe that this could be achieved solely by 8-bit command and get all desired functions; which is why a 16-bit extension command would be necessary that could go right next to the auto-arp command. The extension command could also be used to extend other commands.
Let's call our auto-arp command "Txy" because it goes by tracker ticks. And let's take Exy for our 16-bit extension command.
Txy = Auto-Arp in Sequencer per Y ticks (8-bit/16-bit command)
x = Reference arp table X
y = Next note from arp table X in Y sequencer ticks
if Y = 0 and Exy does not follow then Txy is OFF
if Y = 0 and Exy follows then arp at refresh rate
if Y = >0 and and Exy does not follow, then assume previous Exy or Exy starts as E01
Exy = 8-bit extension to previous command
If previous command is Txy then extend as follows:
x = Arp mode
if X = 0 then arp loop forward
if X = 1 then arp loop backward
if X = 2 then arp loop bidirectionally
if X = 3 then arp loop pseudo-randomly
if X = >3 then assume X = 0
y = Play note plus half-note offset in Txy arp table X Exy Y times before proceeding to next offset in Txy arp table X
If Y = 0 then Txy OFF
So if arp table 0 is "0 4 7 |" and refresh rate is 60Hz then disregard | and proceed as:
For...
C-3-1-F-T01-E02
Play C-3 with instrument 1 referencing arp table 0 at volume F; proceed to next arp table offset every 1 sequencer tick; loop arp at table 0 forward; and play each half-note offset in that table for instrument 1 twice before proceeding to the next offset.
Let's take into account that refresh rate is at 240Hz with the same arp table:
For...
C-3-1-F-T00-E04
This would make C-3 instrument 1 play a slower, forward arp closer to standard refresh.
Also...
Let's say you have a song starting at a refresh rate of 240Hz. How about a command that lags the main player by XX DOPs or NOPs? This way turbo instrument macros could be lagged and amped from and to more standard sounding instruments.
Lxx = Lag engine (8-bit command)
XX = Amount of NOPs (or DOPs maybe) to lag the engine
If XX = 0 then OFF
I think I understand, but this is rather specific functionality. Is this something you've been missing and would use often, and cannot be replaced with more arpeggio macros? It would take some effort to add, that's why I'm asking.
Something I've thought of is adding better support for custom refresh rates in instruments, but I haven't done anything so far because I've seen only very few songs with a custom rate.
I like the idea of being able to mix-and-match envelopes from instruments in general, e.g. use instrument 1's duty cycles and instrument 2's arps. I am not sure any more than that is needed. So I'd make effects something like:
9xx - trigger arpeggio envelope of instrument (of slot?) xx
Wxx - trigger duty cycle/wavetable (depending on instrument) of instrument (of slot?) xx
Xxx - trigger volume envelope of instrument (of slot?) xx
(You can't have it be just one nibble - since there are more than 16 available instruments/slots)
This is something that I believe has been requested for VRC7 too, in a different manner (Effects that let you alter the parameters of a custom patch without having to define a new instrument, such as effects to set feedback, envelope 2 attack, etc. Although you'd need like 10-16 effects in all it would lead to a lot of potential to evolve your instrument over time)
This sounds like Deflemask arpeggio tick. I like it!
_______________________
"im going to continue making this crazy stuff then after a while my style will be so sick that you will be like damn suuun that shit is so sick i dont even get it. i will be like bro its ok.. you dont have to." -omgdonut
@jsr: Thanks for getting back to me. I was wondering if I was just confusing people.
I didn't request these as something that *I* would use on a regular basis but studied a lot of what is in the FTMs on Show Your Work. People use a lot of scales and arpeggios constantly in their music. The "auto-arp" command could essentially allow people to write out a lot of different notes in sequence to be played at the change of command in any order. One arp table could be a major chord, one could be a major scale, other could be a major 7th chord, etc... Being able to change tick spacing means that on the fly people could just update one character instead of copy/pasting a lot if different characters into the sequencer. This could also decrease the size of NSFs and FTMs since it's just referencing a table. Also being able to play arp table offsets more than once in succession makes tracking in higher refresh rates more comfortable; especially if refresh rates are variable within a single song. I believe zzo38 had also requested something along this line. The Txy/Exy commands take practically all these considerations in one.
If a seed is planted for random generation it would be nice for a pseudo-random melody to be played at times throughout the track -- perhaps a harmonic scale? Also if there is a random seed planted other neat commands based on randomness could be done.
Being that currently tracking at higher refreshes is pretty uncomfortable, it would be good to be able to set a refresh lag number and perhaps slide up and down at a particular rate to create nice effects at higher refresh rates. There are many possibilities with this application.
"DOP" is an undocumented 6502 command that equals to two NOPs. I don't know how much effect a single NOP is to lagging the replay engine.
It would take about 21 single NOP instructions to offset 1 sample at 44100Hz.
As far as arps, if I want detailed arp control I actually like to just use speed 2 or 3 and typing in notes. If I don't, then I haven't really found instrument macros lacking.
I wonder if some expressive language for instrument macros might serve the same purpose you're getting at, B00daW? Something like if you type:
0 1 [3 6 4]x2 5 7
When you hit enter becomes:
0 1 3 6 4 3 6 4 5 7
There could be a bunch of operations for building macros quickly.
- Repeat (duplicate string) [2 3 4]x2 > 2 3 4 2 3 4
- Spacing (dupicate entries): [2 3 4].2 > 2 2 3 3 4 4
- Interpolate [8-1] > 8 7 6 5 4 3 2 1
Personally I don't normally mind just typing macros in, but I know a few people have requested a return of the auto-envelope generators that used to be there, and more advanced related ideas.
I like rainwarrior's idea, and I would add onto it a mechanism for 'repeat this but reversed'. Maybe also 'flip from positive to negative' or 'find the highest value N and subtract N from all values in this'
@rainwarrior: I see what you're getting at and possibly as an overall change to instrument macro MML that might be a good idea but it's not what I'm getting at. However, it could potentially make the commands even better!
The "auto-arp" command could potentially be anything scale or melody related. It's not necessarily limited to arpeggios but it uses the arpeggio tables as reference points. The idea is to edit a single instrument instead of supplying multiple instruments and edit their melodies in repetitive fashion supplied by an arp table without a lot of copy/pasting. This way you could also just change instrument numbers in the tracker and it would take on the characteristics of other instruments. Arp priority would be supplied by the Txy/Exy command.
Are you referring to "sample" as the time between one value in an instrument macro and the next?
Preferably to lag the engine at a high refresh rate an even integer equal to one or two entire engine refresh cycles would be desired to lag it. An X counter could be used count down supplied wasted/spent cycles for lag.
I mean a sample as in 1/44100th of a second. That takes about 42 CPU cycles (or 21 NOPs, which take 2 cycles each). DOP should not be used, given how poorly supported this kind of instruction is among emulators. Yes any sort of busy loop of suitable scale would do, I was just pointing out that NOPs themselves are rather short.
I dunno what you would really do with a "lag engine" effect anyway. Presumably you want to put something in the middle of a frame? Don't we already have good working ways to do this? If mixing "fast" and "slow" macros is what you want, I don't think consuming CPU time is something that will accomplish that properly.
The premise is to start off at a high refresh rate like 240Hz. If X cycles are wasted every refresh it could appear that it is at 60Hz, then less cycles can be wasted with the Lxx command by starting off with a high number and going down to a low number to basically "take the foot off the break" and let the engine cycle faster. A cycle lag increment/decrement slide effect like volume slide would be very useful as well for more subtle, less jagged, and more polished effects.
Understand now?
One could also create one tuned noise instrument and use the engine lag command to create additional frequencies. Reference my single noise channel FTM for an example.
Having the NSF consume CPU cycles isn't the way to do that though. Just have it not advance macros for X PLAY calls. It'd be simpler to implement, and function better. (Basically it's just F0x except it's for macros?)
On the NES it doesn't matter if you consume cycles or not (it'll be running the CPU either way) but on an NSF player you get to save CPU/power when the NSF returns from PLAY. (This is something that's kind of a pain about Deflemask NSFs.)
Yes. That is a better way. I agree and understand.
Edit: On second thought, I'm not sure I think it's a good idea after all. If PLAY itself was just not called until X, regardless of macros, it would have a better effect. This way standard arpeggios (0xy) and all other functions based on strings of numbers could be delayed.
.png)
Also if there is a random seed planted other neat commands based on randomness could be done. 