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
I was thinking about how I was going to go about implementing a effect system in a little MSX psg code, when I started thinking about the usefulness of variable arpeggio length in a 0xy command.
Since I dont plan on using it in my system(ornaments and the like, as well as its usefulness as good 'no command' state), I thought where this COULD be useful, and so here we are.
I dont really like 1 interrupt long arps, to be honest, so the 0xy command tends to go unused when I'm doing stuff, and I think the option to change the length of the arps produced by it would be useful.It would also leave open a lot more arpeggio spaces in the insturment field. [color=#F55656]What d'ya think,guys?
_______________________
My DropBox: [url=https://www.dropbox.com/sh/fji37kw0ipztxzh/AACTxuzaWjAJBYVyIPbZKdeoa?dl=0]link
[quote=Xyz_39808]I think that if jsr would implement hertzdevil's Scheme mode for arpeggios, then that'd be solved. [/quote]
If that's the one I'm thinking of, IMHO interesting but too complicated. Simpler just to have a module property dictating the behavior of the 0xy effect (like we already have for vibrato), because I don't want to define custom instruments just for arpeggios; I'd rather just define the arpeggio sequences themselves and use the 0xy effect to reference them directly.
I mean, come on, what is the point of keeping the 0xy effect as-is if nobody actually wants to use it? I know gathering comprehensive statistics would be impossible here, but almost every arp-based song I've seen posted in SOYW uses instrument-based arps instead of effect-based arps. So IMO it's fair to suggest that the effect 0xy is broken currently.
_______________________
Where to find me:
YouTube: [url=http://youtube.com/user/stratelier]http://youtube.com/user/stratelier
DeviantArt: [url=http://stratadrake.deviantart.com/]http://stratadrake.deviantart.com/
imo simpler to just make an instrument with a "0 0 x x y y" arp in Scheme mode and then use that. You could even make another blank instrument with "0 0 0 x x x y y y" to now have TWO different speeds in the same song. Still much more efficient (for the user, no clue how the nsf engine goes along with HeZeD's work)
[edit:more research]
Since nicetas_c can't post, I'll post the effects of the play routine in the changed nsf engine
normal 0xy: ~20 cycles
scheme mode: vaguely about 100 machine cycles every channel (~146 extra bytes of code)
To me, I can see three ways of handling arps, each controllable by a module property setting:
1 - Current behavior (0xy creates two- or three- note arps, changing notes every engine cycle)
2 - 0xy has the same format but iterates every [i]other[/i] engine cycle (which seems to be the preferred speed for 2- or 3- note arps)
3 - 0xy becomes 0xx, where xx is an arpeggio macro number (overriding the currrent instrument's arpeggio setting; disable with 000)
Heck, even just a module property to dictate whether the arp command iterates every 1 or every 2 engine cycles could be very useful already.
_______________________
Where to find me:
YouTube: [url=http://youtube.com/user/stratelier]http://youtube.com/user/stratelier
DeviantArt: [url=http://stratadrake.deviantart.com/]http://stratadrake.deviantart.com/
Upon asking Hertzdevil for more info regarding this topic he had some useful info regarding what'd happen if you implement that 3rd suggestion (and even [i]how[/i] to implement it)
"One possible solution is included in the text file attachment. This is definitely smaller than the arpeggio scheme mod, and allows all instruments to share the same set of sequences to some extent, but much less expressive than arpeggio schemes, since:
A) It is much more difficult to test arpeggio sequences than 0xy parameters using Ctrl+Enter because one has zero information of the sequences in the pattern editor, thus one has to open the instrument editor and enable arpeggio while testing each individual arpeggio sequence
B) Modifying the note parameters on the fly becomes impossible and such usage must be calculated manually and encoded within a single arpeggio sequence
C) Sequence indices are not always representative of the chord notes, as using sequence 71 for the major chord, sequence 56 for the major in 1st inversion, and sequence 105 for the diminished triad in 2nd inversion (wherefore 047 is the current implementation and hex 47 would be decimal sequence 71 and similarly for the other examples)
And now regarding changing the period of the 0xy effect, your proposal is also worse off because of:
A) Since there is no way to control the phase of the 0xy effect and a separate effect to write to var_ch_ArpeggioCycle is not worth the effort at all, the use of longer 0xy effects on multiple channels will create more apparent phase issues, although extra code may be added to reset that phase every time the 0xy effect is encountered (the arpeggio scheme mod does this every time an instrument is loaded in the pattern)
B) There is then no way to use the 1-frame 0xy arpeggio, or any other arpeggio pattern, other than creating new arpeggio instruments for each chord combination."
So yeah, tl;dr is "that idea creates a lot of problems"