Jump to content

kliepatsch

Members
  • Posts

    203
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by kliepatsch

  1. 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!
  2. Now I'm glad that I saw that one 8-bit show and tell video about how to make random mazes in Forth Besides, welcome to the forum, @Alan!
  3. Yes, both YM2151 and PSG channels are used. PCM outputs no sound, at all, but instead generates a timer (see post above). The YM2151 is generally the more useful sound chip. It has better sound quality and it's much more versatile, and yes, it's mainly used for the "melodic" instruments. The PSG channels are mainly useful for percussion, and only some of the instruments. It requires a little more creativity to put them to proper use. The kick and snares are done with a combination of YM2151 and VERA noise channels.
  4. The YM2151 and the VERA PSG are outputting sound. PCM outputs no sound, but the Concerto sound engine currently abuses it to generate a custom timer that is faster than 60 Hz by hijacking the AFLOW interrupt generated by the PCM channel. It may be possible to use the VIA in the future to generate the timer, though, which would free up the PCM channel to do other things. The VIA timer isn't currently implemented in the emulator. I don't know, actually It depends strongly on how much is going on in the music. I am guessing about 25% of CPU. There was another song made with Concerto, that ZeroByte ported to R39 so that it could be run in Box16, which has really nice debugging features. In the debug screen it looked like 20-25% to me, and this composition here may be in a similar region. So there's still plenty of CPU to do other things! The MP3 actually contains the same song two times in a row. I thought it was interesting enough that people would listen to it twice without getting bored So it's rather 2 min. The 27 kB split into: 7 kB sound engine, 4 kB instrument configurations (of which less than half were actually used), 16 kB music data.
  5. adding an mp3 recording of it x16_funk.mp3
  6. It's not my first composition for the X16, I have done two with Dusan Strakl's Music Player Library (MPL) and another simple one with Concerto. But this is the first one where I am pulling all the stops that I know of. Although composing by scripting in Python is definitely tedious, I am actually having a ton of fun It's still unfinished, but reasonably complete to share it here. I hope you enjoy! Runs in the official R38 emulator. TUNE.PRG
  7. I have started 6502 assembly with this website: https://skilldrick.github.io/easy6502/ (Although I've had previous experience with x86 assembly.) I think if you know how to use an ordinary programming language, the most important new aspects in assembly are Processor registers. You cannot simply operate on as many variables as you like (imagine writing a command like a=b+c*d). Instead, you have to work with a limited set of processor registers, which are essentially variables that are constantly reused for new purposes. Processor flags. These are essential for program flow. Instead of writing "for i=1 to 10 do something" or "if a=b then do something", you have to use processor flags and conditional jumps ("branches") to control the program flow. I think when you understood those things, you are good to go Edit: when I wrote this, I was in a hurry. What I meant was, that these two concepts are the extra challenges, anyone coming from a higher programming language should be extra aware of. You should read about these things and get at least a rough idea about them, before proceeding to learn about assembly instructions.
  8. I appreciate the amount of thought you put into this! One little remark from my side: if it's not too much of a hazzle, would it be possible to put the key combinations that are used often (like copy/cut/paste) into a place where one could do the combination with a single hand easily? I've found that using Ctrl+P, Ctrl+U is awkward to use compared to Ctrl+C, Ctrl+V. Just one little feedback
  9. I think I'd wait for your generator That way, Concerto can serve as a test case for your generator.
  10. I see your point, leaving decay away limits the musical use. So the question boils down to whether the intended use includes music or only simple sound effects.
  11. Well, rje has been talking about an ADSR manager for a while now, and I was interested in his wishes specifically. My impression was that he doesn't want a second Concerto, but rather address a simple problem: currently you cannot make a sound with a single line of code (or two). I may be wrong ...
  12. 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?
  13. Would anyone be interested in a C wrapper around Concerto, so you can use it in C programs with CC65?
  14. 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.
  15. I think the frequency/MIDI question boils down to the applications you have in mind. The MIDI to frequency conversion is a relatively expensive operation. It's only worth it if the intended use of such a library would be to play music. In all other cases (e.g. sound effects), it is both more efficient and less limiting to directly set the frequency. Dropping the decay phase makes sense IMO, since in most cases, you either want a short sound (decay = release), or a sustained sound or beep (no decay phase, since you directly enter sustain phase).
  16. @rje What kind of functionality would you think would be good for such a C library? The questions I am asking myself are would you rather set a MIDI note (library handles conversion to frequency) or a 16-bit frequency directly? What envelope parameters are desired? Do we need the full ADSR functionality, or would it be sufficient to define attack, release and hold duration (the time in between attack phase and release phase, potentially zero) (in other words, dropping the decay phase) Should you pass the PSG voice index (0-15) during the function call, or should the library automatically choose a voice? I am thinking that the easiest would be to have a single function to which you pass all required parameters, like frequency, ADSR parameters, waveform. So you can call the function and then simply forget about it.
  17. 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.
  18. BTW the screen capture looks quite nice And it's interesting to see the CPU consumption go up and down with appearing and disappearing objects.
  19. I think you are on the right track. You have got 8 million / 60 cycles per frame, that would be 133.333. When doing such estimates, I usually counted cycles, not instructions. As soon as you know what kind of game logic you want to do for every object, you can start prototyping the most costly algorithms that are required for these updates, and count the cycles that are required for these algorithms. Add a bit of extra, depending on how much logic you intend to have, and you have got yourself a first rough estimate of how many cycles you need to update an object. For example, suppose you find that you cannot get around doing two multiplications while updating an object. Start prototyping the multiplication routine. Let's say it uses 200 cycles on average, so that you have 400 cycles for the two multiplications needed for each object. Let's say you need a fair bit of extra logic/code for the object update, so let's assume 250 more cycles. So your total estimate would be 650 cycles per object. This lets me arrive at 133333/650 = 205 objects.
  20. I cannot follow the whole calculation. I agree on the 1600000 instructions per second, or 26667 instructions per frame. If you update 40 objects each frame, that would be 667 instructions per object and frame. As far as I know, there are hblank and vblank intervals, so the instructions per scan line computation is not as straightforward as it seems. I know this because of the box16 emulator, which has a CPU activity visualization with scan line overlay, and if I remember correctly, there were those hblank and vblank periods. Anyway, you would get less than 2 instructions per scan line and object. So it is not possible to update every object on every scan line. But then again, I don't think that this is necessary. One update per frame should be enough, shouldn't it?
  21. Thanks to all the new managers and moderators! And thanks to the old ones! Your efforts are much appreciated
  22. The red block in the top right corner typically indicates disk activity, and if it persists, some disk operation has probably gone wrong. Some load routines don't work with SD card and there have been known bugs for a long time (ironically, other functions don't work without an SD card image). So I conclude that BRIXX probably makes use of some Loading functionality that's broken when used with an SD card image. But I would have to try this out myself to be sure
  23. I like the approach of setting a pointer and say "go". I'd also think that doing some simple control of playback speed would be possible. But I'd be careful with that as that is moving away from lightweight (in terms of CPU) player more into synthesizer territory. Volume control is definitely out-of-scope, I think, since that requires too much CPU power. Honestly, I think the PCM functionality should just provide play a sample at given sample rate, address and length (perhaps an option to loop the sound). That way, PCM will be useful for drum sounds and sound-effects without consuming too much CPU. But I doubt it would be sensible to use it for melodic instruments, given the YM and PSG.
  24. The big question to me seems how you pass the audio data. Do you support a limited amount of samples that can be reused all the time like in mod files, or do you want to stick to the streaming paradigm even for PCM?
×
×
  • Create New...

Important Information

Please review our Terms of Use