Done in BASIC just as a concept to show what BASLOAD can do. Multi-voice is supported, but seems either the SMC or the PS/2 interface itself is limited to 3-6 keys pressed at the same time (or maybe it varies by keyboard).
VSYNTH-FMFREQ.BASL.TXT / VSYNTH-FMFREQ.PRG original non-multivoice version, but supports more than 16 keys (middle row is arranged about like an octave and a half of a typical piano keyboard, upper row is the black keys)
VSYNTH-PSG.PRG (and VSYNTH.BASL.TXT / KBDHANDLER.BASL.TXT) is the multi-voice version, and also switched over to using PSGFREQ instead. FMFREQ wasn't giving me as much control over the duration as PSGFREQ does.
FMNOTE/FMCHORD is are all neat, but sometimes it is hard to coordinate using this as background audio in your own BASIC programs. If you know the frequency and approximate tempo, then you can just store those in a DATA sequence and control the playing of the next note(s) inline with your BASIC program main loop. And unless you have a lot of experience in composing, it's hard to come up with chords and music in your head - it helps to hear them a bit in real time on the system, or just doodle around the keyboard and experiment with combinations.
But even at 8MHz, BASIC does struggle a bit to process this in its interpreted form. Maybe someday a Blitz build of this will smooth that out. IMO this runs a bit smoother and better on the actual hardware.
So while this does function, there is lots of room for improvement too. But the main intent was it would buffer up sequences, then have an option to export them back out to DATA sequence or BASIC code - so once you had a tune you like to incorporate into your main program, this would generate a snippet of that audio for you (hence why the FMFREQ version pay attentions to jiffies between notes).
X16 Synth (on-system audio from the keyboard)
X16 Synth (on-system audio from the keyboard)
- Attachments
-
- KBDHANDLER.BASL.TXT
- (8.49 KiB) Downloaded 110 times
-
- VSYNTH.BASL.TXT
- (3.3 KiB) Downloaded 89 times
-
- VSYNTH-FMFREQ.PRG
- (1.66 KiB) Downloaded 122 times
-
- VSYNTH-PSG.PRG
- (3.67 KiB) Downloaded 88 times
-
- VSYNTH-FMFREQ.BASL.TXT
- (3.02 KiB) Downloaded 107 times
Last edited by voidstar on Wed Jun 05, 2024 9:23 am, edited 1 time in total.
Re: X16 Synth (on-system audio from the keyboard)
See also - not greatest capability demo, but main point here was to showcase BASLOAD more than the actual synth.
https://www.youtube.com/watch?v=NqYfjphSKok
https://www.youtube.com/watch?v=NqYfjphSKok
Last edited by voidstar on Wed Jun 05, 2024 9:05 am, edited 1 time in total.
Re: X16 Synth (on-system audio from the keyboard)
Probably should have left this in Work in Progress. But it is playable/usable.
Here is an IMPROVED version using the newer/faster keyboard handler. It won't "feel" faster because while the asm is faster, now the BASIC is supporting more than twice the keys (I had a compromise in the previous version that limited it to 15 possible key inputs to keep the channel assignment easy; but of those, only a few can be pressed at the same time).
A good test is trying to play chopsticks (use keys R and T as starting points) - and it's subtle, but you may notice the more you play around with different keys after running, BASIC here starts to slow down making it slightly harder to then play chopsticks as smoothly as it does when the program first loads. That's not great, but it is a good reminder of issues related to how BASIC works during runtime.
The keyboard is now split into an "upper" and "lower" half, to support a broader range of keys (31 key inputs now!!). And that other new feature is the PSG channel used "rotates" across the set of notes. Basically, when you press a note, it is assigned a channel until you release it. The channel assignments just round-robin across ch 0 to 15, so you never really know which key is going to end up with which channel (and that works just since we're limited to pressing only a few keys at a time anyway).
I like FMFREQ, but it starts softening/voluming-out the note right away. So it doesn't give as much control for holding a note steady like PSGFREQ does. I may look back into FMCHORD and other options. There are more options with PSGWAV to also play with. Again, I do like the sound of FMFREQ better, but for now playing with PSG. Might do a split, like the top two rows using FM and bottom two rows using PSG ? But BASIC is already struggling a little bit to keep up as it is (the painful part is probably the concatemer string to show the combination of notes played- probably accumulates lots of garbage strings over time - if you don't care about the notes, you could just comment that PRINT out and get the runtime a bit more smooth)
Do plan to incorporate custom fonts to show the notes in a better way (and to distinguish a lower C from C and higher C, etc), which the faster TILE command can then make use of all that. Also I plan to return back the jiffies/tempo counter (there are two counters really -- how long you've held the note(s), and how long the delay is between notes. I took that out for now since maintain those numbers made it sluggish with this many notes. And I'd like to add a "logger" or way to export what was played back out (since that's one of the main points - to use this to come up with little audio sequences to embed back into BASIC programs). And I'd like to give a more graphical feedback while playing (or an option to do so).
And Wavicle confirms: no matter what I do (via System ROM BASIC), it's going to be limited to about 3-7 keys at a time. It fundamentally comes down to the limited RAM for the SMC to work with. So if you have someone hogging 2-3 keys on the top half, then only 1 key might work on the bottom half. There are some exceptions where you might get 6 or 7 keys going - so maybe this counts as a kind of keyboard-tester-tool also!
Of course those 4 gamepads have lots of inputs - anyone for some multi-player synth? PSG on the kbd, FM on the gamepad?? Hmm!
There is a little TXT file in the zip with some more notes.
Here is an IMPROVED version using the newer/faster keyboard handler. It won't "feel" faster because while the asm is faster, now the BASIC is supporting more than twice the keys (I had a compromise in the previous version that limited it to 15 possible key inputs to keep the channel assignment easy; but of those, only a few can be pressed at the same time).
A good test is trying to play chopsticks (use keys R and T as starting points) - and it's subtle, but you may notice the more you play around with different keys after running, BASIC here starts to slow down making it slightly harder to then play chopsticks as smoothly as it does when the program first loads. That's not great, but it is a good reminder of issues related to how BASIC works during runtime.
The keyboard is now split into an "upper" and "lower" half, to support a broader range of keys (31 key inputs now!!). And that other new feature is the PSG channel used "rotates" across the set of notes. Basically, when you press a note, it is assigned a channel until you release it. The channel assignments just round-robin across ch 0 to 15, so you never really know which key is going to end up with which channel (and that works just since we're limited to pressing only a few keys at a time anyway).
I like FMFREQ, but it starts softening/voluming-out the note right away. So it doesn't give as much control for holding a note steady like PSGFREQ does. I may look back into FMCHORD and other options. There are more options with PSGWAV to also play with. Again, I do like the sound of FMFREQ better, but for now playing with PSG. Might do a split, like the top two rows using FM and bottom two rows using PSG ? But BASIC is already struggling a little bit to keep up as it is (the painful part is probably the concatemer string to show the combination of notes played- probably accumulates lots of garbage strings over time - if you don't care about the notes, you could just comment that PRINT out and get the runtime a bit more smooth)
Do plan to incorporate custom fonts to show the notes in a better way (and to distinguish a lower C from C and higher C, etc), which the faster TILE command can then make use of all that. Also I plan to return back the jiffies/tempo counter (there are two counters really -- how long you've held the note(s), and how long the delay is between notes. I took that out for now since maintain those numbers made it sluggish with this many notes. And I'd like to add a "logger" or way to export what was played back out (since that's one of the main points - to use this to come up with little audio sequences to embed back into BASIC programs). And I'd like to give a more graphical feedback while playing (or an option to do so).
And Wavicle confirms: no matter what I do (via System ROM BASIC), it's going to be limited to about 3-7 keys at a time. It fundamentally comes down to the limited RAM for the SMC to work with. So if you have someone hogging 2-3 keys on the top half, then only 1 key might work on the bottom half. There are some exceptions where you might get 6 or 7 keys going - so maybe this counts as a kind of keyboard-tester-tool also!
Of course those 4 gamepads have lots of inputs - anyone for some multi-player synth? PSG on the kbd, FM on the gamepad?? Hmm!
There is a little TXT file in the zip with some more notes.
- Attachments
-
- VSYNTH-PSG.PRG
- (2.94 KiB) Downloaded 75 times
-
- VSYNTH_0_8.ZIP
- (5.73 KiB) Downloaded 79 times
Re: X16 Synth (on-system audio from the keyboard)
With my keyboard, I could get max 4 keys at the same time.
I also tried to set the typematic rate to 2 keys/s, and the delay to its minimum value (250 ms). I just wanted to test if anything improved if less key events were to fill up the SMC buffer. But it didn't change anything.
The Kernal is capable of fetching 60 key events/s from the SMC. That would correspond to 30 keys held down at the same time when the repeat rate is 2 keys/s. The limitation might be the keyboard and not the SMC.
I also tried to set the typematic rate to 2 keys/s, and the delay to its minimum value (250 ms). I just wanted to test if anything improved if less key events were to fill up the SMC buffer. But it didn't change anything.
The Kernal is capable of fetching 60 key events/s from the SMC. That would correspond to 30 keys held down at the same time when the repeat rate is 2 keys/s. The limitation might be the keyboard and not the SMC.
Re: X16 Synth (on-system audio from the keyboard)
With X16 emulator and laptop keyboard, I found I could do this combination:
Q-E-T-U-O-X-B-, (comma)
(8 key combination, which yes the arrangement is rough for human hands to press! but so far it is the most simultaneous notes I've found it could play) Be aware, some keys aren't assigned on purpose - like keys 1,4 and A,G (since the arrangement I picked was to be similar to the piano, where not every white key has a corresponding sharp above it).
By the weekend I should be back home to try on real hardware via the PS/2 keyboard to see if it can match that. To make it easier, the generated "NOTES$" string could show the actual key pressed rather than the music note.
I get the "historic" limitation across the original Commodore PET keyboard matrix (if "first contact" along the matrix "wins" that then prevents keys further along that series from being signaled until the earlier one releases -- or at least, something along those lines, which is why across rows you get more success at signaling multiple key presses at a time). So make sure you are trying across rows, like the number-keys at top and Z-M at bottom.
It's still a bit odd to me that some of those limitations still linger (I mean the inconsistency of which key combinations can be supported). For example, I cannot do combination of keys X-W-V or X-W-R (can only do two of those combination groups, not all 3 - or each one individually). But I can do X-W-F.
Q-E-T-U-O-X-B-, (comma)
(8 key combination, which yes the arrangement is rough for human hands to press! but so far it is the most simultaneous notes I've found it could play) Be aware, some keys aren't assigned on purpose - like keys 1,4 and A,G (since the arrangement I picked was to be similar to the piano, where not every white key has a corresponding sharp above it).
By the weekend I should be back home to try on real hardware via the PS/2 keyboard to see if it can match that. To make it easier, the generated "NOTES$" string could show the actual key pressed rather than the music note.
I get the "historic" limitation across the original Commodore PET keyboard matrix (if "first contact" along the matrix "wins" that then prevents keys further along that series from being signaled until the earlier one releases -- or at least, something along those lines, which is why across rows you get more success at signaling multiple key presses at a time). So make sure you are trying across rows, like the number-keys at top and Z-M at bottom.
It's still a bit odd to me that some of those limitations still linger (I mean the inconsistency of which key combinations can be supported). For example, I cannot do combination of keys X-W-V or X-W-R (can only do two of those combination groups, not all 3 - or each one individually). But I can do X-W-F.
Re: X16 Synth (on-system audio from the keyboard)
Update 0.9
Now has a custom font. Reduced down to 21 keys, all along the center row. I didn't really like the "wrapped keyboard" arrangement in the prior build.
Performance is better, but still not fast enough to really keep track of two timers (time-between notes and time-held-notes-down) using interpreted BASIC. The killer is implementing the change-detection (i.e. has any notes pressed changed since the last iteration) - I added a way for, changing the old NOTES$ string to a more bit-packed way, but even that induced a more sluggish key response.
I may have to do some tricks using the timers in VIA#2 to track those times, but I was hoping to a full record/playback feature (in mostly interpreted BASIC). Seems even 8MHz still isn't quite enough.
But without that, this version you can actually jam a little bit
Try It Now!
Now has a custom font. Reduced down to 21 keys, all along the center row. I didn't really like the "wrapped keyboard" arrangement in the prior build.
Performance is better, but still not fast enough to really keep track of two timers (time-between notes and time-held-notes-down) using interpreted BASIC. The killer is implementing the change-detection (i.e. has any notes pressed changed since the last iteration) - I added a way for, changing the old NOTES$ string to a more bit-packed way, but even that induced a more sluggish key response.
I may have to do some tricks using the timers in VIA#2 to track those times, but I was hoping to a full record/playback feature (in mostly interpreted BASIC). Seems even 8MHz still isn't quite enough.
But without that, this version you can actually jam a little bit
Try It Now!
- Attachments
-
- VSYNTH0.9.zip
- (7.1 KiB) Downloaded 69 times