Commander X16

As promised, here is a quite a big update to Concerto. The most notable changes are:

• 
  Concerto is now licensed under the BSD-2-clause license: You can use it in your own open AND closed source projects!
  


• 
  The YM2151 is now integrated into Concerto. Freely combine VERA-PSG and YM2151 to create your sounds! You can even modulate the pitch of the YM2151!
  


• 
  Reduced number of PSG oscillators per timbre from 6 down to 4 for lighter memory usage.
  


• 
  Load/Save named single timbres and banks (a bank is the entirety of all 32 timbres that can be loaded at the same time). Filename editing made possible by adapting code from the awesome VTUI library made by @JimmyDansbo
  


• 
  Factory sounds are included (load bank "FACTORY" from SD card to view them).
  


• 
  Internal optimizations, the PSG sound slightly changed compared to previous versions.
  


• 
  Cleaned up UI from unused stuff
  

I have NOT added support for the YM2151's internal LFO. For the time being, Concerto's own LFO can at least do vibrato, even though it doesn't sound as nice as the native LFO (I guess), but let's keep things simple for now.

The last things I want to add before going v1.0 are automation of volume and vibrato (similar to the already implemented pitchbend).

 

Unfortunately, I haven't gotten loading of FACTORY.COB (the sounds that come with concerto) in the "Try it now" section to work. It works flawlessly locally with an SD card image loaded. I have read that the filename extension must be whitelisted in order for it to work. I read that ".SEQ" and ".PRG" are okay. I have also seen ".BIN" being used successfully in the Web emulator. I have tried using ".BIN" earlier today, but with no success. I am using the Kernal routines to load and save. Maybe I am doing something wrong there? Do I need to set the secondary address to a specific value for it to work?

 

If you have an SD card image loaded into your emulator, and the FACTORY.COB file is on there, you can enter the file name "FACTORY" in Concerto (no extension needed, Concerto adds that for you) and click "LOAD BANK". Then you can view all the sounds that I made so far.

I am slowly approaching the point where Concerto has all the features I want it to have. I've been working on vibrato ramps and volume ramps, which seem all to be working now. Concerto will also include an (optional) song player module together with a predefined song format. You have already seen it in action in the demo I uploaded a while ago:


From now on it's mainly about improvements, minor tweaks and bugfixes. Concerto already comes at a hefty size of >10k low RAM requirement. Have been thinking about how to put parts of it into high RAM, but that seems really difficult, since there is so much back and forth in the entire code. And up to now, no one has asked for it ? Also, I changed my mind on going v1.0. That will not happen as long as the real X16 hasn't arrived.

Hi all, recent progress on Concerto led to the release of version 0.5.0-alpha.

Find the source code on Github together with ready-to-execute precompiled examples that show you a glimpse of what you can do with Concerto (and how it's done in the example source files): https://github.com/biermanncarl/cx16-concerto

Additions to the functionality:

• 
  Concerto now includes a player module. The entire sound engine can be automatically controlled using a new data stream format. The format is specified alongside the source of the player. CC65 assembly projects can use the player by simply including the source file of the player.
  


• 
  Vibrato and volume automation have been added and are available in the API (and can of course also be controlled by the player)
  


• 
  Timbre data can now be included at compile time. This can save a lot of annoying file operations at runtime when all you want is to statically load a certain set of sounds. Simply include the "bank" file that can be exported from the Concerto UI, which contains 32 sounds. (Note that you still have to get this file off the SD card image. Concerto can't save files to the emulator's host file system)
  

The user API has been made simpler and more secure. This also introduced several breaking changes.

• 
  API calls now do not use any of the R0-R15 pseudo registers for passing parameters. Instead, parameters are passed using CPU registers wherever possible, and Concerto's own registers anywhere else. This is to prevent the "public" R0-R15 registers getting messed up by Concerto.
  


• 
  From now on, it is not necessary to include a separate file for the zeropage segment. Instead, Concerto handles the assignment to the correct segments itself (and restores the previously active segment using CC65's .pushseg/.popseg directives).
  


• 
  It is now not necessary anymore to call SEI/CLI before/after certain API calls. Simply calling the subroutines is enough.
  


• 
  The VERA address registers are backed up and restored by Concerto's interrupt service routine. It is now safe to use the VERA alongside Concerto, even without calling SEI to prevent Concerto messing with the VERA. This was highly due!!
  


• 
  The way Concerto dumps / restores timbres got changed.
  

Other changes include:

• 
  Bugfixes
  


• 
  Reasonable default/center pitch when pitch-tracking is deactivated
  

System requirements:

• 
  about 11k low RAM (19k with UI)
  


• 
  15 bytes ZP usage (21 with UI)
  


• 
  stack usage: 20 bytes of stack headroom should be safe (a couple more with UI)
  


• 
  CPU usage: almost nothing up to most of it, depending on song and timbre complexity. For a normal song, expect something like 20%.
  

I am also thinking about facilitating recording to the ZSOUND stream format, which will be less CPU intensive for playing back songs. I am guessing the resulting song files will be huge, but we still need to try this out. Maybe it is very well worth it ?

Now, since there is a song player with Concerto, it would of course be nice to be able to compose music for/with it. I have written a couple of Python scripts that help me with generating binary data for the player (which is how I composed the above demo). But this process is very tedious and not enjoyable. I am still thinking about how to improve this situation.

Would anyone be interested in a C wrapper around Concerto, so you can use it in C programs with CC65?

I'm really interested to see how much space a ZSM generated from Concerto would consume. Writing the ZSM generator module is higher up the priority list for me, but if you'd rather build it into the Concerto engine directly, let me know and I'll help.

I'm not sure if I understand the difference between the two approaches. You are developing a general purpose generator that can be plugged into any software, and I could either wait for that or write my own routines that exports ZSM? Is that what you are saying?

Yeah that's what I am saying.

I've been doing some planning for how I expect to implement it - going to have to rope off a good bit of HiRAM as a buffer to generate the data into. Of course, that would be specified by the client application when calling its init() function.

I think I'd wait for your generator ? That way, Concerto can serve as a test case for your generator.

Hi all, just wanted to drop a note here on the current status of Concerto. Since my life has changed in the past months and will further change in the next couple of months, I have much less time to spend for hobby projects like this. (Read: got a job, will get married). It's great to see things moving again, and the emulator being developed further to better match the X16 expected hardware.

If anyone is interested in getting Concerto to work for newer releases of the emulator, feel free to drop me a message, and we can discuss. I don't think it's much work, but right I am not doing it for the sake of it ? 

(also there is always the option to fork it)

All the best!

Been working on a ZSM recorder lately. An X16-native ZSM has been recorded in the emulator with Concerto. See this post in the creative arts thread.



Concerto-generated ZSM data in a typical song can be assumed to yield between 1 to 3 kB per second in 127 Hz tick rate (which is Concerto's native rate). This will be lossless and sound identical to Concerto itself playing it if played back at 127 Hz. It could theoretically be compressed to 60 Hz playback rate (lossy) and save about 50% of storage size.