NESizer wishlist

[jeff464]

After (finally!) being able to play with this for a few hours, I had a few ideas come to me. I'm not sure how feasible any of this is, so take these suggestions for what they're worth.

Idea: Ability to save MIDI channel voice assignment per patch, instead of globally.

Why: Some patches require stacked voices, but there doesn't seem to be a way to un-group the assignment if I need those voices separate later in the song.

Idea: Ability to hear parameter adjustments in real time when editing on the unit itself.

Why: Currently the user has to make adjustments blindly and it's not until one clicks "ok" that they're able to hear the change. MIDI CC adjustments are real time - it would be a quality of life improvement to have that on hardware as well.

Idea: Ability to create arps per voice/patch.

Why: Currently the user has to create the arp manually in the sequencer, and this may not always be an option. Famimimidi allows arp creation per patch, and it would be great to see that here.

Idea: Table for pitch, etc on an instrument level - think LSDJ or c64

Why: Famimimidi has this baked into some of the presets and it allows for modern sound design, interesting percussion, and delays. This might require a massive rewrite, so not sure how possible this is.

Idea: Noise loop mode placed at higher octave, opposed to having a separate mode.

Why: LSDJ/mGB has the different noise modes available as different octaves as standard and it allows for seamless switching during the song, instead of entering a different mode during playback. This way allows a greater variety of possible rhythms.

Idea: Pitched samples

Why: Most of the charm of sample playback is what it does to higher/lower pitches. It would be nice to either set the playback pitch of the sample on the NESizer, or set the ability to allow for key ranges where the user can place samples at different pitches.

Idea: Sample channel offset

Why: It looks like MIDINES had MIDI CCs implemented for sample offsets, etc. This allows for interesting effects like time stretching and wave scanning. I'd love to see the sample channel receive more attention. MIDINES info can be found here: https://wayfar.net/0xf00000_midi_chart.php

Idea: S/H & Noise shapes for LFO

Why: Because it's fun.

I'm certain I'll have more ideas pop up as time goes on. Also, it's very possible that some of these might already be possible and that I may have missed something in the posts here/manual. In that case, my apologies. ;)

Completed/implemented features since the original post:

Program change over MIDI
Separate LFO shapes per slot

[Jaffe-]

Great list! Some of these should be fairly easy to do I think.

One that might be tricky is the pitched samples. It is possible to some extent, but the pitch control would be somewhat coarse and non-linear. But it would be interesting to try, just to see how it can be used. It might also be possible to do this by resampling the audio before transferring to the NESizer.

When you mention rate of Env Mod, isn't that really just a question of changing the attack and decay parameters, or am I missing something?

[jeff464]

Ah! Yes, you are absolutely correct about Env Mod. Never mind the request. It's obvious now that I know that it's related directly to the ADSR. The manual didn't explicitly say this, but, yeah, it's sort of in the name "Env Mod." :)

If I'm understanding the dilemma regarding pitching samples, if I pitch (down) before sending to the NESizer, it's very possible that the sound could take up a lot of space. A use case for a sample pitching function would be to import the sound at a higher speed, and then pitching down once inside the unit in order to save memory. Personally, I wouldn't mind it being non-exact as it might end up being an interesting experimental effect. Currently, I'm using NTRQ for custom NES sample playback, so NESizer would be an ideal improvement to this method.

[circuitcreature]

I started looking into the sample pitch control, but will need to do more research. I think it would be totally fine with the way the CPU changes pitch, multiple samples would be needed to have a complete scale. It would be awesome to get some of those Sunsoft bass lines.

[jeff464]

That's awesome! I feel like most of the DMC charm is how it mangles audio at the lower octaves, but yeah, additional samples would certainly be needed for a full scale. Sunsoft was on a different level, for sure!

[beau-seidon]

I have the pitched sample playback working ALMOST perfectly. The main issue I'm running into seems to be buffer overflow or underflow when reading/skipping bytes of the sample, which I am not experiencing on my AVR DDS Wavetable synth I made. It operates by the same algorithm I'm using here.

After reading through the hardware docs, I now think it may have something to do with the way the latches are used to address the memory, but I'll have to think about it some more, then test it. A "modulo 19" or something in my phase increment might just fix my problem.

I have uploaded everything so far to a branch on my fork, but if you want to play with it, please be aware that you will have to pull your coin cell battery the first time you use it to wipe the SRAM, because I added a couple new options to the UI Programmer. The new software will cause your interface to go haywire until you clear the memory. This will unfortunately wipe any loaded samples and erase your saved patches as well. You will have to pull the battery again if you decide to revert.

To select "Sample Loop Mode 2" for pitched sample playback, increment DCM Loop ( DCM + 1st button of 2nd row) up to 2. Then use the newly mapped square button (DCM + 2nd button of 2nd row) to select your sample for pitched looping.

Those are the primary changes I had to make: Add new loop mode and change interface options to enable it. Everything else works same as before but the new mode still has one major bug as stated above. It makes some pretty gnarly sounds tho, even with a simple sine wave as the sample. I may record and upload some of them for your entertainment.

[beau-seidon]

After adding the checks for device ID, I'm still having intermittent issues loading samples via SysEx, but I think it may be MIDI-OX problem.
(I know for SURE I found a MIDI-OX bug when trying to send batches of SysEx files using its COM API.)

I have made some changes in a local branch to the way NESizer parses SysEx messages which makes patch changing via SysEx work perfectly, but it is still screwy with sample loading. Tonight I'm going test loading samples using ALSA amidi on my Linux machine and see if that helps. Might also try clearing all my NESizer settings and RAM because I have been pumping it full of garbage. I'm still trying to rule out buffer overload / race condition.

I also fixed a bug in the way the 7seg display function displays error messages, by adding a function which can display arbitrary combinations of LEDs with a comment block that shows how to use it.

When I have unborked my SysEx sample loading I'm going to implement:
Idea: Ability to save MIDI channel voice assignment per patch, instead of globally.
because I can already see how to do it without breaking things.

[beau-seidon]

Got it working! Going to make sure it uploads all my previous samples with no issues tomorrow then post the update.

[jeff464]

Stoked to test this out!

[beau-seidon]

https://github.com/beau-seidon/NESizer2/tree/master
includes MIDI CC, SysEx and/or PC patch change option, and SysEx sample loading. see the midi/sysex.c for a couple comments on how to format messages if you want to test, but patch changing via MIDI ProgramChange is easier at least with my controller. if you are using a DAW like Cakewalk, they make scheduling SysEx events a breeze

[beau-seidon]

Looking for some feedback on ProgramChange patch select feature:

I just noticed that in FL Studio the program change drop down menu is labeled 1-128, but program 1 sends 0x00, program 2 sends 0x01, program 3 sends 0x02 and so on. In Cakewalk they aren't numbered at all, just labeled with the General MIDI instrument set.

My keyboard pads are configurable to send PC# 0-127 so that's how I programmed it. I have mapped them to 0-99.

Is that how y'all want it? Or do you have a 1-99 preference, where 0 is just left a default patch or something?

[beau-seidon]

The only perk I see to 1 - 99, is that it would line up with the General MIDI numbering and not be confusing when using a DAW.

[circuitcreature]

I think the general midi numbering would be the way to go. This way we can avoid any one specific DAW

[beau-seidon]

Just to be clear, the General MIDI number scheme is 1-128, but the actual ProgChg message numbers that are transmitted are still 0 indexed (0-127) at the byte level.

My only argument against General MIDI is that my MPK Mini Plus keyboard shows them as 0 indexed when I set up the controls (when I send PC#5, NESizer goes to patch 05) and I assume others do too. I'll have to look up the data sheets for a few of the most popular MIDI controllers to be sure.

The choice is between confusing DAW users, and confusing DAWless performers lol. That's why I asked for help choosing. Someone is going to bitch about it either way.

[jeff464]

Just updated my unit - I think program changes are great how they are now. Everything seems to line up one-to-one with anything I'm using it with.

[beau-seidon]

Sweet. If you're happy with the way it behaves, wanna mark the request in the list above as "complete"?
Maybe format the Program Change list item with strikethrough (add ~ symbols before and after the text).
Just to keep track of what's implemented.

[jeff464]

I'm a big ol' dummy and just now realizing that documentation says nothing about patch/bank exporting/importing. Is this possible? I'm not too confident my patches will survive an extended period of time.

If there's no current way to do this, I'll have to add this to the top of my wishlist, along with pitched sample playback, for as janky as it may be. :)

[circuitcreature]

@jeff464 Totally forgot to add that into the manual. It's CC 24. I'd have to dig back into the code again, but from what i remember is that it is applied to LFO settings.

[jeff464]

Ah! Makes sense! I also noticed there's no MIDI CC for Octave listed for the SQ or TRI channels. I see "Octave Shift" but I assumed this is related to the keyboard split function since it doesn't change the sound any.

[jeff464]

So it looks like my NES displayed the dreaded "CR" before erasing all my samples and patches. Oddly enough, the (different) sounds on my other unit are still intact. They were both powered off for approximately two months.

The battery checked out fine when testing. Pretty bummed about this! Those patches took fooooorrrrrreverrrrrr.

[beau-seidon]

Damn. Sorry to hear that. I'll get back to work on sysex patch export/import again and bump up its priority on my to-do list. Not that it helps you right now...

[jeff464]

I mean, obviously no rush at this point. :D It was more to post as a warning for anyone reading this. It shouldn't be too difficult to eventually rebuild some of the layered patches. Though, I'm confused as to how this happened. Maybe I shouldn't be using a 9v DC1000mA power supply?

If I can find the time, I'd like to eventually build a patch editor/library to speed things up a bit.

[circuitcreature]

@jeff464 On the midi CC side you will need to change the value by increments of 14, I believe, but I haven't tested this. Looking at the code it has a possible 9 values and these will be broken out over the range of 128 for midi CC.

Could you test the Octave shift on the actual device, page 5 in the manual?

That will help track down the issue.

[jeff464]

The octave function works totally fine on the unit itself, but MIDI CC 95 has no effect. MIDI CC 123 also seems to be non-functional.

[jeff464]

Added "tables" to the wishlist. Not sure how feasible this is, though!

[jeff464]

Added "sample channel offset" to the wishlist.