PatchTool.hex

Topics on software tools like TileStudio, comments on documentation and tutorials (or the lack of) should go here.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: PatchTool.hex

Post 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.
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: PatchTool.hex

Post 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:
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: PatchTool.hex

Post 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?
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: PatchTool.hex

Post 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).
Post Reply