nesdev.com

Oh I see, well of course I would be the last person trying to wave a flag and bitch about why something is not being developed further instantly, I've got a lot of time to do it as well from what I can tell so I don't depend on anything here, if necessary I'll go with the text version. If needed eventually, I'd be happy to find useful similarities between Pently and Famitracker, but like dougeff said, it might be unnecessary.

For example, demanding the use of certain instrument names in Famitracker, so that upon conversion, certain Famitracker instruments can be interpreted as instruments or attack settings.

With the release of NovaSquirrel's ft2pently, I have decided to tag commit 1b5311d as Pently 0.05wip4 alongside it. It contains fixes for defects discovered during the development of ft2pently.

• Project moved to GitHub
• pentlyas.py: proper argument parsing
• pentlyas.py: options to read input from stdin, write output to file
• pentlyas.py: option to generate period table (requested by dougeff)
• pentlyas.py: writes data sizes in bytes as comments in output (requested by NovaSquirrel)
• pentlyas.py: turned some internal exceptions into informative error messages (reported by NovaSquirrel).
• pentlyas.py: treats r and w the same in drum patterns (requested by NovaSquirrel)
• pentlyas.py: parentheses for slur for LilyPond parity
• Legato note overwrites uninjected attack's pitch (reported by NovaSquirrel)

By integrating (optional) period table generation into pentlyas, I have made less work for anyone who wants to compile a py2exe version. Reading input from stdin could allow piping ft2pently's output through pentlyas. The data size diagnostic helps a composer see how close a project's score is to its byte budget without having to parse hex numbers out of an ld65 map file.

The legato problem made grace notes more difficult to use with instruments that have longer attack phases, which are more likely to occur in automated conversions. Early versions of Pently (through 0.03) did not support FamiTracker-style envelopes. Instead, notes either sustained at their starting volume or decayed linearly from their starting volume, just like instruments in NerdTracker II. Pently 0.04 added an attack envelope to all pitched instruments as well as a fifth track that inserted attacks into another channel. (The attack track concept was inspired by "Super Mario Land NES-Mix" by Phlumb-Dumb.)

Versions of Pently with attack envelopes also have an arpeggio effect, as well as a legato effect that changes the note on a channel to a different pitch without restarting its envelope. (Legato on a woodwind instrument corresponds to notes that are not tongued, and on a guitar, it represents hammer-ons and pull-offs. In NT2, a note is played legato by not giving it an instrument number. In FT, it's done with the most rapid portamento-to-note, like 3FF.) In previous versions of Pently supporting attack phase (0.04 through 0.05wip3), a note played legato would change the pitch only of the sustain phase. This didn't cause problems with the idiomatic Pently instrument type that has a relatively short attack and an NT2-style decay on the sustain. But because a converted FT instrument's sustain phase (the last step of its volume envelope) cannot decay the way an NT2 instrument can, the attack phase (all steps but the last) has to be made much longer. I originally had legato not overwrite the attack's pitch so as not to interfere with an attack injected by the attack track. But I found a way to distinguish attacks on the channel's own track from injected attacks and modify only the former's pitch, by taking advantage of a different hack I added to pause a channel's arpeggio while an injected attack is playing and restart it once the attack ends.

[This post put me over 2^14.]

Today I figured out how to make a musically consistent yet computationally efficient vibrato control.

Vibrato adds a sinusoid to the note period. FamiTracker's vibrato is typical of tracker vibrato, which makes the depth constant in period units. This means that for higher pitches, which have lower periods, a given amount of vibrato depth will sound stronger than it does for lower pitches, which have higher periods. But if the change in period for a given vibrato depth setting is proportional to the note's own period, it'll sound the same for low and high pitches.

I've also found that looping the vibrato once every 12 frames (roughly equivalent to FamiTracker effect 45y for depth y) is within normal limits of vibrato on a string or wind instrument.

This, however, leaves portamento as an excuse.

When I made a spreadsheet to double-check the pitch table from the wiki (it has a few rounding errors) I think I had some kind of column with how many bits a sweep needed to be, but I forget what condition I put on it.

I came to the obvious-in-retrospect observation that you get one extra bit of period (be it in its simple play-this-note or the amount you need to sweep to get to the next note in N steps) each octave.

More progress.

0.05wip5 (2016-06)

• Vibrato effect
• Simplified zeroing of channel state during song start
• Pattern effects use RTS dispatch
• Corrected namespacing of some APIs
• Standardized names of feature defines (PENTLY_USE_*) and moved them to pentlyconfig.inc
• Feature defines to disable vibrato and arpeggio effects, counting rows per beat, attack track, and the attack envelope entirely
• Split manual into separate documents for concept overview and bytecode description because with pentlyas and ft2pently, few need to deal directly with bytecode
• Applied MIT License (Expat variant) throughout

Please expound this statement.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

A song consists of a set of patterns and a conductor track, which tells which patterns to play when. In pattern bytecode, codes $00 through $D7 produce notes and rests. Codes $D8 through $DE enable or disable effects, and $FF terminates a pattern. The changelog entry states that effect codes, which had previously been processed using a compare/branch tree, are now processed with a jump table that uses the RTS Trick. This makes the code more maintainable, especially as I add effects (like vibrato) or remove them (the .if commands to leave out code related to vibrato or arpeggio).

Ok, that clears it up, thanks.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

This just killed support for romhacks, But whatever, Not my problem.

Though it makes things harder for anyone using this for anything but homebrew!

_________________
AKA SmilyMZX/AtariHacker.

How so? MIT is not a copyleft. Though Nintendo is known to be anti-copyleft, I seem to remember that some of the Wii system software has notices for BSD and MIT licenses. If you want, I can go try to dig it up for you.

Licenses like that only allow you to go so far before you get sued,

I was planning to try to use in a SMB2 hack to enhance music, but since the MIT licence says this:



And after that, the problem area is:



Meaning all uses of the music code (at least legally) MUST NOT be included with copyrighted code originally made by Nintendo.

Also, Fair use don't apply here.

_________________
AKA SmilyMZX/AtariHacker.

All it really means, with respect to my copyrights, is that your hack must give me credit where copyright notices usually appear. In this notice, "the Software" refers to Pently, not any other larger work that includes it. For example, if you are using Pently as a plug-in to replace a game's music engine, see answers to "Can I use MIT licence plugins in my commercial web site?".

If you're referring to the practical problem of including the license text in a sub-megabyte executable, I'll have to think about a good way to clarify that including the notice in the manual is acceptable.

Oh, That is fine then...

_________________
AKA SmilyMZX/AtariHacker.

Effects I can add next include

• Portamento to note
• Detune channel
• Channel volume (reuse one instrument for forte and piano sections)
• Master volume (fade out)
• Envelope looping instead of sustain phase

Which of these would be most valuable to composers?

The problem with just adding them all is RAM use. On average, each effect takes 2 bytes for each channel that it affects: one for the parameter and one for the current state. So that's 8 bytes if an effect affects only actual channels or 10 bytes if it affects a track (including the attack track). If I added all the effects, RAM use would climb back into the range of heavyweight engines even for soundtracks that aren't using a particular effect. I can't just use .res controlled by .ifdef because I'm storing the channels' state somewhat interleaved: four bytes for pulse 1, then four for pulse 2, etc. for correlation with the offsets in APU MMIO space ($4000-$400F).

So I might have to think of a more clever way to pack state variables needed by those features that are enabled, using ca65 macros if I can or Python if I can't.

I find volume control to be one of the most important effects. Every channel, preferred.

Also, down the road, ot would be nice if we had a library of instruments, so every musician doesn't have to reinvent the wheel (or piano-ish volume envelope, for example).

_________________
nesdoug.com -- blog/tutorial on programming for the NES