Jump to content

m00dawg

Members
  • Content Count

    62
  • Joined

  • Last visited

  • Days Won

    2

m00dawg last won the day on January 4

m00dawg had the most liked content!

Community Reputation

34 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Overriding my previous comment as I made sort of a BIG change which I think could help reduce the amount of bytes for non-zero rows: | If Note Flag Set | If Vol Flag Set | If Effect Flag Set | Channel : N/V/E Flags | Note : Octave : Inst | Pan : Vol | Next Effect Flag : Effect # : Effect Data | 5-bits : 3-bits | Nibble : Nibble : Byte | 2-bits : 6-bits | 1-bit : 7-bits : Byte | So now instead of an effect length, there's flags that explain what the next bytes are. N is note, V is vol, and E is effect. his allows for having rows that are just manipulating notes, volume, effects or all these. So say if we're just manually changing volume, that would only require 2 bytes. Order matters in that, if we have all 3 flags set, the next byte after the flag is the note data, followed by the volume column, then at least one effect (could be more, see below). Here is where it gets interesting. If the effect flag is set, we know there will be at least one effect, but now there is an effect flag that says if there is another effect defined. This means there could be, in theory, N-effects but the storage requirements are the same - it just means there are now "only" 127 definable effects. That seems like way too many, even with macros, since effects can be unique per sound-chip, though many effects would be common to at least VeraSound and FM (like volume slides, portamento, arpeggiation, etc.).
  2. This peaked my interest. I'm not sure what you mean by bench computer? Are you referring to using the X16's GPIOs to do logic probing kinda stuff or something else?
  3. Actually on the contrary, while it may be fun to do all this myself, that's a pretty big lift! And the ultimate goal for me is having a tracker on the X16 so I can make music with it. Once there is a MIDI interface, perhaps in tandem with a modern DAW; but I'm looking forward to the offline isolation of a dedicated tracker running right off the X16. I suppose there's a small part of Nostalgia at work there but not much as I do find using my modern DAW can be pretty distracting. Even if I just unplug the damn network cable, Windows still wants to make sure that I know that my online account isn't sync'd just in case I changed my mind, in addition to myriad of other nonsense. So yeah, anything that gets the closer to the finish line I'm all about! The portmento in particular is something I didn't know quite how to implement. I assumed it was similar to what I was thinking a pitch slide would be (in the tracker case, it's a shift and offset is how I thought about it, though I haven't yet looked at, say, Famitracker, to see how it does it) but with a end frequency to shoot for (namely the note that was played). In any case, when you get down to it, what makes a tracker is mostly the UI and approach. I think the only thing potentially special about a sound engine for it is, like we discussed previously, channels are typically hard set to particular hardware voices where the composer decides how to use what channels. This has benefits for being of being able to saturate channels more. I like I could use PSG channel 1 for both a chip bassdrum, hi-hat, and maybe an arpeggiator within the same track. The above is no longer true some modern trackers, like Renoise but in the case of the X16 is how I was going to approach it as it's still sort of "standard" when looking at say Famitracker or Deflemask and this makes the file format more straightforward. This concept doesn't really save any screen real-estate either - I think in the case of Renoise, being largely a sampler at the end of the day (though it has VST and MIDI support), it makes a lot of sense, especially with its out of tracker automations it can do. Not sure how familiar you are with trackers so forgive me if I'm rehashing what you already know, but essentially you define notes and effects on a piano roll using, typically, a concept of instruments. The instruments would set up defaults and be where you might define a default envelope, etc. They make more sense for FM but even with the PSG make sense - you can setup a "pluck" sound that has a short volume envelope on it, optionally along with a PWM envelope to give it a nice timbre for the pluck. Then you might have a bassdrum which is a fast pitch slide down also with a volume envelope. Then in the patterm data, I tell it what note, octave, instrument, and optional effects I want. Something like: 16: C-4 02 F D04 So at row 16, play a C at octave 4 with instrument 2 at full volume (F), and add a volume slide (D04). My current file format definition allows multiple effects, so there could be D04, G37, ... I'm not sure if I will keep that yet as another way to do combination effects is with macros (or instruments with their own automation if the effects don't need to be modulated). I also though about allow different envelopes to be selected on the tracker data but I need to see how that might fit into the effect column while trying to keep the pattern data small. I said all that to say a tracker could surely use a sound engine probably without too many modifications? I wonder if any modifications that would be needed might be something that can be added to the engine. It would be pretty amazing if both an X16 tracker and DAW used the same engine. In fact that might not be the only thing that can be shared - a MIDI solution could be one that might be shared by both. A tracker tends to be a little more limited here - one could set it up to output MIDI but that seems like a bit of an odd solve on the X16. It could read incoming MIDI as an alternative means to edit patterns. Primarily for me, I'd like MIDI sync so I can use the X16 is sort of another instrument in my greater orchestra as it were. I'm super rambling sorry haha I thing long story short, it makes a ton of sense to me for really all the music and sound applications to be able to reuse and share as much code as possible. A tide lifts all boats kinda thing. So yeah I'd be quite interested in learning more about your engine, absolutely!
  4. You mean like the link in my initital post? It's Gitlab, but basically the same thing: https://gitlab.com/m00dawg/commander-x16-programs/-/blob/master/command_tracker/index.md I actually found out today, kinda by accident, that Atom has a Markdown preview and it seems to work rather well!
  5. Ah thanks for the info! Yeah valid workaround, although the Markdown files are the easiest to see I think. Hopefully interested folk are compelled to click on those since there's support for rendering tables and things. Although Markdown was meant to look "good enough" when viewing as text, so I suppose attaching the raw markdown would work too!
  6. Moved my ideas over to another thread since I kinda moved it a bit far off-topic from this one.
  7. Given VERAsound will now replace the SAA1099, and given some other conversations on the forums (such as the conversation about envelopes in this post), I opted to take another look at my proposed tracker file format, which you can find here: https://gitlab.com/m00dawg/commander-x16-programs/-/blob/master/command_tracker/index.md I've talked about this before on the FB group, but I've opted to stop using FB and thought it would be a better conversation had here anyway. The main issue is that there are 26 channels so to optimize for storage on playback, a sparse format is probably worth the extra complexity in playback routines. I had the idea of supporting multiple effects since this is a common feature in modern trackers (even FamiTracker has this). That may go by the wayside, but even if each channel only had single volume and effect columns, I came up with 5 bytes per channel for VERASound and FM and 3 bytes for DPCM. So a single row would be 126 bytes and a 64 row pattern would be 8064 bytes! The file format I came up with can support multiple effects per channel, and when you include these it balloons to a staggering 41.6k if I did my math right. But given even complicated patterns have empty space in them, by using a sparse format these requirements go down considerably. Only rows which have data are defined and, within that, only channels which have data are defined. So a row can be as few as 3 bytes if there's only one channel playing on that row with no effects. I made an attempt to show the proposal row format here but I can't find a way to insert code blocks and it was really hard to read without a monospace font. So I recommend looking at the link (specifically the sparse patterns link) The trade-off is a playback routine has to track a lot more things as opposed to just reading a pattern row by row. I don't think it would be too terrible since there could be a row counter and if the current row read is greater than the counter, nothing is done. When the counter equals the current row, it then can parse out the row to do the things. This ignores envelopes and some automatic commands (like how the volume slide works in Famitracker as compared to how it works in Impulse Tracker) as those could be firing while there is no row data. Figuring out how to efficiently edit pattern data is another task entirely though. If one adds data to a previously empty row, the sparse file would have to be reorganized. The best solution here is having a non-sparse pattern buffer - which would be fine for a dedicated tracker where we have room to move about. But given the space requirements, it means patterns would span multiple pages and that could get interesting when adding in things like envelope tables and things. I should say I'm not an awesome assembly programmer - just a musician who is very excited about the prospects of a tracker, but given the vast sound capabilities of the X16, it feels like it will take some thought to do well given the "limited" space (which is itself far more than the 8-bit systems of yesteryear). That's why I thought it might be good to try and start the conversation by coming up with at least something that can serve as talking points.
  8. Self reply fail, but thought I would share my thoughts in maybe a more succinct way, so created a quick envelope format definition here: https://gitlab.com/m00dawg/commander-x16-programs/-/blob/master/command_tracker/file_formats/envelopes.md I think it could be further optimized. For instance, on a playback routine, once we know if we're looping or not, and where, we really just need to index into the envelope positions. The way I defined it, if an envelope isn't looping, the next byte after the header is the first step in the envelope and the code then just needs to follow that for the envelope length. If there's loops, the next 2 bytes define the loop start and end. This is probably trivial for some or lacking in details for others, but figured I would put my thoughts somewhere. The other files might be useful but were when the SAA1099 was around and I haven't put any thought into how the VERA PSG would change things (for one there are now more channels).
  9. Yep I thought about this as well, plus simple add/subtract per "game tick" or vblank for some of the linear effects, like an in-pattern volume slide rather than an actual envelope. The Axy effect in Famitracker-speak. If I interpreted the docs correctly, the VERA will handle the logarithmic nature of the volume, so we only have to think of it as linear. So a volume slide down is just subtracting a constant from the set volume. Envelope tables wouldn't be too bad given the 6-bit volume. Could even add panning automation since you get the L/R for free. So that's 1 byte per step. In Famitracker, my average envelope length is usually say 5-8 steps for most instruments. I sometimes used a few longer sweeping envelopes for pads and strings but tended to do that more via pattern data (using Axy as noted above). Some RAM will be needed for which envelope is being used and at what position - that's 32 bytes for all 16 channels I think. All told using an 8kb page would be plenty I think for envelope tables. Even 1kb might be plenty, leaving room perhaps for other things for that page (like instrument definitions or some such). Since the waveform and pulse-width are also packed into 1 byte, the same thing could be done for PWM with being able to switch instruments within the envelope as a weird bonus In thinking about the L/R and waveforms - a better use of the top bits in these envelopes might be a loop flag or some such, though given the space we have, could also set aside a byte or two with the envelope to track loops and optionally an envelope speed modifier maybe (like if you wanted the envelope to go slower and only update say on every X vblanks). Given the frequency calculation on the VERA, note tables would be a nice to have too. For standard tuning (A=440Hz), that could be another use case to put in ROM as well. 8 ocatves is 96 notes which would just a 192 byte (given the 16-bit pitch values) table. That way folks can just think "play an A#" instead of figuring out the math to get what frequency that is. If folks want to use non-standard tuning, that can be done by adding/subtracting from the table. So yeah hmm given me lots of ideas there Stephen!
  10. Expansion hardware is a great point. I still think between all the options discussed across the forums that one of them will stick So I have to imagine we'll have some sort of file copy solution - other than Sneaker Net. I'm just not sure which one. I would imagine the simplest one will be the first one that works (and that sounds like some sort of user port solution is my guess - or perhaps the IEC port). I think I'd be less bothered by SD cards if they weren't so small and were more purpose made for frequent insertion and removal. Something between an SD card and 3.5" would have been nice, with slots intentionally made for the purpose. Micro-SDs are even worse - I've lost several already behind my desk and that's where they're staying. I have to swap SD cards between devices several times a week and it ends up being a pretty big annoyance for me and they definitely do wear (both the SD cards and the readers) if you swap cards a lot.
  11. Ooooh snap I hadn't though about slides either. Or for that matter any other effects like PWM slides, arps, etc. NES had the hardware pitch slide stuff, and while I never quite understood it I could make some really fun rowdy noise effects. That might be a bit more intensive on the X16 perhaps?
  12. Is it though? There's not yet a serial solution available, though given all the things discussed, I'm sure there will be one. I was thinking you were suggesting using the IEC bus as one of the solutions since it already exists. The idea seems to be, given the SD card is at the back of the computer, that one won't be removing it from the X16 all that often. But for active development, that could happen _a ton_ and likewise for sharing content made (you know like tracker files, demos, etc.) one will have to yank the card. I have to do this all the time with my 3D print farm and it's a pain (as an aside, I do it this way because OctoPrint isn't as reliable for me as just printing right from the printers and it really sucks to ruin a customer print because Octo print disconnected from the printer, or the Pi just stopped working, etc.). So having a way to copy stuff back and forth without having to remove the SD card all the time is something that I think would have very high value.
  13. Ah maybe I misinterpreted, I thought you were saying the IEC bus could be a good way to enable getting data to/from the X16 and, say a PC?
  14. Right and of note, if comparing to the NES, software envelopes don't have to be overly precise here. In looking at the docs, a routine to update the volume of all 16 channels would be something like: Set $9F20-9F22 to $1F9C2 Set skip to 4 via high bytes of $9F22 For each channel: LDA $VOL STA $9F23 Forgive the awful pseudo code haha. Basically setting the VERA addresses to point to the PSG registers, setting the skip so we only update the volume on each pass, then doing it 16 times for all channels. That's the most basic case though - each channel may have a different software envelope, so in reality I would guess there's going to be some sort of LUTs that comprise the envelopes that need to be read to know what value to set. I'm kind of assuming how it works in, say, Famitracker here, but for compact code, I wonder if it might use less memory to have compacted tables (and to skip envelopes altogether for instruments that aren't currently using them). Or hmm for simple things, like the equivalent of a volume slide in a tracker, those are usually linear (in terms of an envelope) and would just be subtracting the current volume by some constant. Now I'm getting a little excited haha. Of note, since we have stereo we can do some really nice 8-bit chorus stuff in stereo (ala "The MegaMan" chorus but in stereo!)
×
×
  • Create New...

Important Information

Please review our Terms of Use