Page 2 of 2

Re: PatchTool.hex

Posted: Fri Oct 02, 2015 7:00 am
by Artcfox
I'm not sure if the workflow that most people use to design sound effects involves running PatchTool on actual hardware, or inside of Uzem.

I think I've run it on both, and end up either taking a cell phone photo of it on my TV screen, or taking a screenshot of the Uzem window so I have a "hard copy" of my patch file, and then I look at that photo while I'm translating and typing it into my .inc file.

After making a longer than usual patch, I was thinking "Damn, I wish there was a better way to turn this into code without having to translate and type it all in!" And then I got to thinking, well maybe I could do OCR on the screenshot, and then write a script to expand the abbreviations, but to be honest, that sounded pretty gross too.

But what if you used the two whisper ports:

Code: Select all

#define UZEMCHR _SFR_IO8(26) //uzem whisper port for outputting characters to the console
#define UZEMHEX _SFR_IO8(25) //uzem whisper port for outputting hex bytes values to the console
and wrote a function that printed out the full non-abbreviated version in its full glory like:

Code: Select all

const char patch[] PROGMEM = {
0,PC_WAVE,1,
0,PC_ENV_SPEED,20,
1,PC_PITCH,95,
1,PC_NOTE_UP,2,
1,PC_NOTE_UP,2,
1,PC_PITCH,100,
1,PC_NOTE_DOWN,2,
1,PC_NOTE_DOWN,2,
1,PC_PITCH,95,
1,PC_NOTE_UP,2,
1,PC_NOTE_UP,2,
1,PC_PITCH,106,
1,PC_NOTE_DOWN,2,
1,PC_NOTE_DOWN,2,
1,PC_PITCH,95,
1,PC_NOTE_UP,2,
1,PC_NOTE_UP,4,
1,PC_NOTE_UP,8,
1,PC_NOTE_UP,16,
1,PC_NOTE_CUT,0,
0,PATCH_END
};
to Uzem's console window?

Then it would just be a matter of copying and pasting that into your patch.inc file, changing the name of the patch, and you'd be done!

IIRC, the Uzem from the uzem140 branch always has the whisper ports enabled, while they can be enabled with a flag in the Makefile of the Uzem from the master branch.

Re: PatchTool.hex

Posted: Fri Oct 02, 2015 8:08 pm
by uze6666
I use the old way of making a test program, making changes to the patch, compiling out and running to hear. I was not fond of the idea a manually recording everything. But your changes is pretty valid and efficient for the job.

The way I always wanted it was to read and write to a file using the Sd interface. You would run the HEX from you /data directory and it would parse you patch file. Make changes and save to the patch file directly. Add Uzebox keyboard support and you have a pretty awesome tool. :ugeek:

Re: PatchTool.hex

Posted: Fri Oct 02, 2015 8:53 pm
by Artcfox
uze6666 wrote:I use the old way of making a test program, making changes to the patch, compiling out and running to hear. I was not fond of the idea a manually recording everything. But your changes is pretty valid and efficient for the job.

The way I always wanted it was to read and write to a file using the Sd interface. You would run the HEX from you /data directory and it would parse you patch file. Make changes and save to the patch file directly. Add Uzebox keyboard support and you have a pretty awesome tool. :ugeek:
SD read/write support would indeed be the cat's meow, but that sounds like it would be a pretty major overhaul, no?

Re: PatchTool.hex

Posted: Sun Oct 04, 2015 8:39 am
by D3thAdd3r
The tool itself is pretty old and is missing some critical feature that would make it a lot more useful; and I recall there was a fairly critical bug with the way it handled unsigned numbers. I have lost the source however, which I seem to do frequently. There was no real SD card support at the time, so actually getting the data to your patch file was never quick and eeprom hackery did not seem quick anyways since you'd have to modify the data to extract it with a separate program. Still no Uzem SD writing available so that is not an option yet, perhaps port write could be logged to an output file or something. Personally, I still use the tried and true save and recompile method as it's more productive.

I'd say it would be better to write from scratch if someone was inclined, the only thing to know is it was using the kernel's ram patch to work. IF the tool supported keyboard/copy/paste AND handling multiple patches in a file while being able to update that file it might compete with the speed of the save+compile method. I don't think that would be easy to do. I don't recall, but there may be some way to extend the kernel to have more than 1 ram patch. VERY useful would be the ability to playback a song and change the patches in real time. I do think that would be faster in that case than save+compile and we would end up with better Uzebox music as a result(the patches make the real difference there).