Commander X16

1 hour ago, TomXP411 said:

The only difference between piano roll, tracker view, and an event list view is the way the data is presented. 



On a piano roll, you are simply drawing a graph where X=Time and Y=Note. Other information, like velocity (volume), modulation, pitch bend, and other parameters are usually shown as a segment or line graph below the roll. 



On a tracker view, you are listing the events on a grid where Y=Time and X=Channel or effect type.



No matter the display format, the underlying data structure is the same. Each event consists of a time index, an event type (note on, note off, patch change, controller change), and a data value (note number, controller value, patch number)



The rendering time is going to depend more on the size of the display than on the presentation method.  

It's a bit more complicated than that though. If using a piano roll, it's expected you can do chords and to me the fundamental method of handing what music is by instrument vs by channel. The software could do some trickery to be able to cleverly reuse channels I'd imagine, but that would be handled more by the software. The trackers, by contrast, hands that over to the musician.

So elaborate on my previous example, say I have something like a SID chip that only has 3 voices. But I want to do more than just chords, so I would interleave other sounds in between when the chords aren't playing. So channel1 might play the base note, but then also play a bass drum. Channel2 the middle note, but then might interleave a melody in between. Channel3 might be doing some rhythmic stabs.

In a tracker, that's a frequent tool to add more apparent channels than there are but you can also more precisely control effects while keeping channel usage in check. When I have more channels, I tend to use fewer tricks of course, but it's an interesting way to think about it and sometimes I wish I did this more with modern music. For instance, if I'm using my Deepmind, I might want to map voices to multiple patches and change them around. I *CAN* do that already but in a modern DAW it's a lot more work than just changing an instrument number in the pattern data within a tracker and I often don't think in this way. Instead I'll record the synth to audio then add the other part in after, which kinda also breaks the creative flow.

Likewise I have a MidiBox SID (actually a monster MB6582 I just finished) which has EIGHT SIDs in it. You'd think that would allow me to create some insane things, but interfacing with the chips via MIDI and a DAW, while I can make some incredibly complicated individual patches, is overall a bit more limiting than if I were to more precisely control each SID voice directly. I can do that, but it's real complicated to do in a DAW, but would be trivial in a tracker.

I'm not trying to speak ill of piano rolls mind you - actually I'm fond of them as well and I think they are much more approachable than a tracker interface, which can be quite intimidating at first. I just wanted to elaborate a bit on the power of trackers which shouldn't be overlooked.

Now ALL that said (and it was a lot, sorry!) - with a rich sound implementation like the YM2151, there's enough channels where folks can write lovely music without resorting to full on tracker trickery to the point that a more musical interface could make sense. Likewise the chip is kinda built around the concept of "instruments" which lends itself more favorably to composing music more with that frame of mind. Tracker-music often sounds different than erhm not-tracker music for lack of a better term, and I think there's plenty of opportunity for both approaches to eventually exist on the x16. I'm eager to see what the final sound design is though!

Good stuff everyone! ?

Yes, I am currently thinking it from the data structure side. Yesterday, I implemented a rudimentary player that works quite well so far. (Actually just to be able to test the sound engine better, which is still a WIP)

The format is dead simple: Everything is an event. Note-on, Note-off and wait are currently the only events available, but all modulation stuff will be events, too (defining points and/or slides, rather than only points as in MIDI modulation).

The player processes one event after another. It keeps processing events until a wait event is encountered. Then it waits for the specified amount of ticks until the next event. (A tick currently being something like 7 milliseconds)

The computational effort for this format while playing back is minimal. But the format will be very annoying to write an editing program for. Imagine just how much data you need to move around to insert a single note. (And the effort it takes to determine the correct position, maybe splitting existing wait events in two etc.) But I think that is just how it is. I like the simplicity and flexibility of the format.

The task is now to think of ways to present that data. Thanks, @TomXP411 for your sketch. It's really helpful to be able to see it! How did you make it? I'd like to be able to make such sketches myself. And your idea about how editing might work is definitely worth considering. (BTW that extra area at the bottom for editing velocities etc. is what I meant by "more infrastructure necessary" ? )

And I am also with @m00dawg. I totally want those kind of tricks to be possible.

BTW I think I am decided to make the whole program "channel" based. That means that we will have 16 channels, where each channel can play a single monophonic note. That makes note addressing (for both note-offs and modulations) waaayy easier than a polyphonic track layout. Also, instruments will be separate from channels, so that every channel can play all instruments, so that those interleaving tricks are possible.

However, that doesn't mean that it will have a tracker layout. In fact, the discrete timing of a tracker might be very impractical for a tick-based timing of al events, and I start to like TomXP411's idea.

19 hours ago, m00dawg said:

If using a piano roll, it's expected you can do chords and to me the fundamental method of handing what music is by instrument vs by channel. The software could do some trickery to be able to cleverly reuse channels I'd imagine, but that would be handled more by the software. The trackers, by contrast, hands that over to the musician.

Yeah, I strongly agree with all the points in this post (and not just the part I quoted).  With later, fully developed MIDI systems which can have polyphony on a single channel, the piano roll does make more sense. But we're not looking at that here; and as @m00dawg describes, trackers let you more directly control what goes to which channel of which chip.

You could still make it work on a piano roll; if you understood it would show one monophonic channel at a time, and there were an easy way to switch between which channel is being displayed.

On 12/18/2020 at 6:04 AM, kliepatsch said:

Yes, Zoom will be nice. I have to think about that. Mouse will be a requirement.

Is anyone even working on a mouse for the X16?  Hey, we get SNES controller ports, right?  Maybe you can make your music app compatible with the SNES mouse. (This is a joke, please don't actually do that: SNES mice are hard to find and awful to use.)  I guess there's always the strategy where the D-pad (or the arrow keys for that matter) move the cursor like a mouse, instead of moving from one discrete screen character to the next.

As much as I dislike the tracker-style interface, as much as I would rather see @kliepatsch make a piano roll, the more I think about it the more the tracker is starting to make sense.  If you can find a good way to break the tracker out of its tendency toward (at least visually) locking the user in to a rhythmic grid, then maybe that's the best way after all. 

In any case, I wouldn't really get started until we know which sound chips we're getting.  The FAQ is still vague about it.  I mean, you couldn't even plan how many columns a tracker would have, or how many data points you'll need under the piano roll, until we know which chips we're even programming for.

EDIT:

@TomXP411's sketch is really good, I like the look of it already.  I think you'll want to sacrifice 1-2 more rows in order to add a label to the X-axis (that'll be especially important if you manage to implement zoom).

6 hours ago, John Chow Seymour said:

Is anyone even working on a mouse for the X16?

There's going to be a PS/2 mouse port, and I'm using that interface extensively with the XCI game engine, and even for small demos like MakeWave

On 12/20/2020 at 12:28 AM, John Chow Seymour said:

In any case, I wouldn't really get started until we know which sound chips we're getting.  The FAQ is still vague about it.  I mean, you couldn't even plan how many columns a tracker would have, or how many data points you'll need under the piano roll, until we know which chips we're even programming for.

Don't worry. I am doing this mainly for fun, and for that, the emulator is equally as good as the real hardware for me ?

If the PSG is cancelled, well, then my whole sound engine can't be used on the real hardware. But the concepts of song composing can still be applied to whatever sound system will be found in the real thing.