Search options (Page 39 of 39)

Scratch that, I've just made it better.

Now, you just specify the Speed Table index, $00-$1F. Then in the table itself, if the speed setting is lower than $20, its treated as a frame counter, otherwise it's used in a overflow calculation. So;

00:03 00        ;set frame counter sped 3, loop

or

00:50 00        ;set overflow counter to $50, loop

Perfect!

DAMN YOU O'HARE!

Actually I've just put both in and it works fine. Needs a bit more thinking about though as currently;

$00-$1F = index into pitch table using frame counter, $00-$1F
$80-$9F = index into pitch table using overflow method, $00-$1F

which is not the most obvious thing in the world but it does work.

I forgot to say that you can get some "extra" resolution from the frame counter method by specifying a loop between two values in the speed table;

00:03 01        ;speed 3, jump to step 1
01:04 00        ;speed 4, jump to step 0

which would be slightly slower than speed 3 but slightly faster than speed 4, and so on.

Plus you can do the "swing feel" trick using the same method;

00:02 01
01:02 02
02:04 00

etc.

Actually, gentlemen, I could do with some input.

While on the subject of speed tables, I have a quandary. As far as I know there are only two methods of doing "tempo" on a fixed refresh rate system (i.e. NTSC being 60fps, constantly).

Method one is using a frame counter. So your "tempo" is the number of frames in between each tick.

Method two utilises arithmetic overflow. You keep adding the "tempo" setting to an internal counter. When the resulting number exceeds 256 (8 bits), the carry flag is set. This is when you do your next tick.

Method one offers the most stable timing as it's always based on a factor of 60fps e.g. a "tempo" of 3 would have a delay of 180 frames between each tick. However, this means that you have little in the way of tempo resolution as the smallest difference between one tempo and the next is 60 frames.

Method two offers you more resolution (I won't get into why) but is less stable because, depending on the speed, every X ticks, it will miss an update. This shows up as tiny fluctuations in your song tempo.

So the question is, which one to use for NTRQ? You've all probably more experience of trackers than me so I'd value any input.

Dare I say I've thought of a way of maybe having both. Maybe... but forget I said that for the time being

(Oh, alternatively, if any of you are programming-minded, is there a better way of doing method 2? I've heard some people doing the same thing but with a 16-bit counter instead but I can't see how this would improve the stability?)

Shit, dudes, this is getting exciting!

Extra effort on my part to get back on track after my little redesign. It's progressing OK at the moment, adding a new editor mode always takes a while.

I've also come up with yet another editing mode which will make things even better. Can't decide whether to do that now while I'm in that frame of mind or put it at the bottom of the list. LOL

I'm so glad I did the redesign to fit in the Song "Master Track". Having the ability to use repeat/jump commands has meant there's not so much pressure on maxing out the space for patterns.

This always happens. As I was typing that big post a genius idea popped into my head regarding the Song Editor. I've always wanted to get a speed table into NTRQ (it actually has one internally) but I had totally no screen space for it.

On Sunday I thought about the layout of the Song Editor and how it was a bit wasteful to always display the Transpose setting for each pattern (that's the "40" you can see in the columns of the song). And then the solution came to me.

To edit values in the Song Editor, most of the time you're using the (A) button, holding it down to modify the numbers with U/D/L/R. (B) was being under-used so my solution is to normally display just the Pattern numbers but if you hold (B), the Song "flips" and shows you all the Transpose values so you can edit one. Let go of (B) and the song display snaps back to showing  Pattern numbers again.

Multiple benefits:

- the width of the Song Editor is halved so I can now have the speed table displayed and editable
- I now have the space for an extra column in the Song which will be used for "master track" type stuff e.g. repeating song steps, setting tempo, setting volume, fading volume
- smaller Song Editor = faster screen updates
- it actually looks better, more symetrical

I had to really break the code to make it work but it's up and running again now (though I have generated quite a list of stuff to fix/check). Here's what it looks like (click the link underneath for full-size);

NTRQ Layout 5

I would love to but I (currently) wouldn't know where to even start.

A mad idea I was thinking of (and I don't even know if such a thing exists or is possible) would be an optical CV-to-MIDI gadget that you could point at a particular area of the screen and I would flash a small white square on screen in time with the refresh rate of the song. Then these pulses could be turned into MIDI clock (with some smoothing) and so NTRQ would be MIDI master clock to your slave devices.

That's probably insane I know