Commander X16

By default, the Zsound player resamples time to 60hz regardless of the ZSM tick rate, but you can play back files at the native tick rate if you use a time source like VIA timer IRQs to drive the playback function. You'd need to either call set music speed = 60hz and then call the playback function at the actual speed in order to do this, or else call stepmusic directly on each tick (stepmusic doesn't preserve things like bank / VERA data port states, so plan accordingly if calling that).

I've got an internal variable in the code that specifies whether the player should scale to 60hz or not - just no way to manipulate it in the API yet. Would this make more sense as an argument to the zsound init routine, or as an API call to enable/disable it? I'm thinking init() argument makes more sense, really....

On 11/4/2022 at 7:38 PM, ZeroByte said:

You'd need to either call set music speed = 60hz and then call the playback function at the actual speed in order to do this

That's amusingly counter intuitive to me. I would have expected that the player "knows" at which speed it is running and advances the ticks accordingly. But it always thinks it's going 60 Hz, so you have to change the song speed instead.

 

Is that variable you are talking about the choice between the different kinds of functions where one advances as many ticks as required, while the other one doesn't care and always advances one tick?

If that's the case, I would probably not expose that, but infer it from the user parameters. Instead, I would let the player know at which frequency it's running so it can figure out by itself whether it's running at the same frequency as the song or not.

Just my gut feeling. This approach would need more work. It would also mess up the nice "divide by 60" function ... That would be a shame.

On 11/4/2022 at 4:36 PM, kliepatsch said:

That's amusingly counter intuitive to me. I would have expected that the player "knows" at which speed it is running and advances the ticks accordingly. But it always thinks it's going 60 Hz, so you have to change the song speed instead.



 



Is that variable you are talking about the choice between the different kinds of functions where one advances as many ticks as required, while the other one doesn't care and always advances one tick?



If that's the case, I would probably not expose that, but infer it from the user parameters. Instead, I would let the player know at which frequency it's running so it can figure out by itself whether it's running at the same frequency as the song or not.



Just my gut feeling. This approach would need more work. It would also mess up the nice "divide by 60" function ... That would be a shame.

By default, it expects you to call it at 60hz, and it will resample time to 60hz automatically when you start a song. If the song's play rate in the header is 120hz, the player will tick the music twice per call to playmusic.

So in other words, you do nothing, you call it once per frame, it converts the song speed automatically.

There is a routine to set music speed (.XY = hz) - when you call this, it adjusts the tick rate to whatever you specified instead of what the song specifies. So let's say your 120hz tune is playing and you call setmusicspeed = 240. You continue calling playmusic once per frame, but now the song will tick 4 times per call, which means the music will now be 2x normal speed. And yes, you can ask Zsound what the normal speed is at any time using the get_music_speed API call. You can use the reply from this to then set_music_speed back to that value.

What I was describing above is for cases where you don't want Zsound to automatically resample time for an assumed 60Hz call rate. The procedure is a workaround. If you set_music_speed = 60Hz, then the player will only advance the music by one tick per call. The player doesn't have any idea how fast you're actually calling it - so if you have a, say 700hz tick rate song, you can call playmusic at this rate and the music will play at normal speed.

The API call I would present would be either a parameter on the initialization (enable/disable time scaling) or else have an API call that disables/enables time scaling. Essentially, set_music_speed(60) disables time scaling. When time scaling is disabled, you can ask what the tune's rate is (or just go read the header from memory if you prefer) and drive the player at that frequency yourself. The main reasons to do so would be if you had more timing-sensitive effects in the music. (e.g. if the Concerto tunes came out sounding wrong at 60hz, you could opt to drive the ZSM at 128hz directly which would eliminate such errors).

Hi all,
It's been a while and from time to time I keep coming back to Concerto. The next thing I plan will likely be called "Concerto Multitrack". It will basically be a piano-roll based, multitrack capable music composing tool on top of the Concerto synth engine. The piano roll editor is now functional (from my point of view), which I think was the hardest part. There are some obstacles before a first release still, but I hope I can make it

Concerto Multitrack is supposed to be a proof of concept for piano-roll based music making on the X16. But at the same time, I want it to be usable as a music composition tool in its own right. What I have in mind for a possible future expansion is to have an arrangement view, as well, with clips one can loop, move around, copy etc.
All the best!

A bit worried about porting to newer emu versions though, having browsed a little through the forum ... I am still on R43

kliepatsch wrote: ↑Sun Jul 07, 2024 10:27 am A bit worried about porting to newer emu versions though, having browsed a little through the forum ... I am still on R43

Conversion from r43 should not be very arduous it may even work as is. There have been fewer and fewer "breaking" changes since r43 and theoretically "no breaking changes" after r45

Ok thanks for the clarification!
One problem I have is the fact that in a speed-critical part I rely on BBS/BBR instructions. If 65C186 compatibility is a must, I would have to look into that.
Also, is there any information on the alternative FM sound chip? Scrolling through the X16 docs they only mention the YM2151.

There's a way to check in your program for presence of that cpu and you may be able to jump to a different version of the routines if it's detected or not?

That would be a good option, thanks
I thought maybe (as it's multiplication routines) I could leverage VERA FX. I saw it provides some assistance with multiplications. But if that turns out to not work so well for some reason, some self-modifying switch point would make for an efficient alternative. Always good to have fallback when there's uncertainty.

For completeness' sake, I'm going to post this here, as I posted it on the discord, as well.
A minimal effort demo showcasing the current status
https://youtu.be/GyfnLRouNjs?si=hzoYZjoa_eHdo-Kq