Feature requirements?

[Beanow]

It looks like most of the Katana projects have significant overlap in their implementations, hence I stared working on this shared library. You can already see some work happening in the branches https://github.com/katana-dev/lib-katana/branches

Not everyone's source code is available to me, so I can't check if I'm missing any vital components.
So I thought now is a good time to ask which features would be must-haves to make it worthwhile to migrate to the shared library.

One consideration. File I/O and MIDI connectivity you need to implement yourself. As this is very environment and application specific. So expect byte arrays and strings to be your typical output for you to route them into MIDI ports or files.

Some I have on my list now:

• Proper semver and libtool release versioning.
• Unit and integration testing.
• SysEx message processing and generation.
• The exposed checksum algorithm.
• In-memory representation of a patch.
• In-memory representation of the full Katana memory.
• Mapping 7bit byte arrays to addresses. (these 60 00 01 12)
• Mapping .tsl parameter names to addresses.
• Manipulating single / bulk patch parameters in-memory.
• .tsl patch loading and generation.
• Snapshot and bulk upload strategies.

Some nice to haves:

• Integration testing with some C++ / Python bindings.
• Compact binary patch format.
  (Early research suggests 300-750 bytes per patch, while a .tsl is about 25KB per patch)
• .tsl minification, if possible, see Map out minimum required tsl parameters docs#5

[Beanow]

@snhirsch @gumtown

[skconrad]

there have been open discussions on what are possible "end goal" hardware / software

Gumtown has two Katana projects - the Editor, and his small "Katana Patch Loader

https://www.thegearpage.net/board/index.php?posts/24008492/
Gumtown wrote>
Here is something new, still being developed, but this first stage is functioning..

Katana Patch Loader

Version 20170427
https://sourceforge.net/projects/fxfloorboard/files/experimental/

For windows, mac, and linux

[​IMG]

A software to load real-time Tone Studio patch file bundles into the Katana modelling amp, by receiving standard midi patch change messages.

Tone Studio patch file bundles can contain up to 128 patches, and are loaded into the Katana with a corresponding midi patch change message from a software controller or mid foot controller.

Easy setup steps.

1.) Load in a Katana patch file bundle from the “File open” menu.

2.) Select midi controller device and Katana from the “Preferences > Mid/USB” menu.

3.) Start playing, midi cc# messages are passed through from the midi controller to the Katana. Your Katana will now be able to access up to 128 patches for live playing.

Latter features for assigns will be added to give realtime midi controls over most Katana parameters.

https://www.thegearpage.net/board/index.php?posts/24008855/

_With the Linux version of the Katana Patch Loader, you could get a small micro computer device,
like the Raspberry Pi3 or BeagleBone board, with them running Ubuntu Linux, have the patch loader setup for headless auto-run (once you have the patch bundle file and midi device selection done previously).
The small board would fit inside the back of the katana cabinet, and just plug in your USB or midi foot controller.

A portable solution to instant access to 128 Katana patches at the command of your toes._

[skconrad]

^^ -although it becomes clear to me that a cheap Android 6.01 smartphone with USB OTG port might make a useful platform for hosting this - benefits from having a touchscreen and color display for user setup - just mount on a custom Katana floor controller and add a long USB cable to the Katana.

[Beanow]

When it comes to patch loading the library would definitely go a long way.
Crudely how I envision that:

1. Open a patch file using an I/O library native to your environment.
2. Use lib-katana to parse the patch and store it in memory.
3. Use lib-katana to generate SysEx message to upload the patch.
4. Establish MIDI connection using a library native to your environment.
5. Send lib-katana generated patch upload messages.

All the current programs (floorboard, patch loader, midi bridge, android editor, ...), already implement this in different ways. Having a library may save everyone some time maintaining this and make it easier to create new software for different needs.

[CodeSmart63]

Personally with a PIC controller (MIDX-20) at hand with totally 64kB code for a boot loader and all the other MIDI stuff in the MIDX PLUS currently two Amplifier Bridges I very much tip toe myself around.
I'm afraid any Library will be "general" and "great" but however not small enough for a very small environment. Also I have only a handful data bytes left. The code I've written is not much code but more tables. For instance the addresses I'm using is represented by a enum BYTE number representing the base address + an offset BYTE. See below. This saves me two bytes per address.

I don't even have floating point arithmetic for scaling. So to scale a Katana number to a CC range of 0-127 I have stuff like this using integer arithmetic:
#define Scale127To51( val ) (val/2-val/10 )
#define Scale127To52_103( val ) (52 + (val/2-val/10) )
#define Scale127To100( val ) (val-val/5-val/43 )
#define Scale127To17( val ) (val/8+val/63 )
#define Scale127To14( val ) (val/8-val/70 )
#define Scale127To10( val ) (val/12 )
#define Scale127To40( val ) (val/3-val/50 )
#define Scale127To7( val ) (val/17 )

This saves two bytes every time....

enum ADR_BASE
{
BASE_00_00_04,
BASE_60_00_00,
BASE_60_00_01,
BASE_60_00_02,
BASE_60_00_03,
BASE_60_00_04,
BASE_60_00_05,
BASE_60_00_06,
BASE_60_00_07,
BASE_60_00_10,
BASE_60_00_12,
BASE_7F_01_01,
};

Example:

#define KAT_CC_FX_FIRST 30
const CCMapper fx1_map_chorus[] = {
{KAT_CC_FX_FIRST+1, {{BASE_60_00_03, 0x3D}, SC_100 }}, //--> 00 .. 64 Low Level (0..100)
{KAT_CC_FX_FIRST+2, {{BASE_60_00_03, 0x3A}, SC_100, }}, //--> 00 .. 64 Lo rate (0..100)
{KAT_CC_FX_FIRST+3, {{BASE_60_00_03, 0x42}, SC_100, }}, //--> 00 .. 64 Direct Mix (0..100)
{KAT_CC_FX_FIRST+4, {{BASE_60_00_03, 0x3B}, SC_100, }}, //--> 00 .. 64 Low Depth (0..100)
{KAT_CC_FX_FIRST+5, {{BASE_60_00_03, 0x41}, SC_100, }}, //--> 00 .. 64 High Level (0..100)
{KAT_CC_FX_FIRST+6, {{BASE_60_00_03, 0x3E}, SC_100, }}, //--> 00 .. 64 High Rate (0..100)
{KAT_CC_FX_FIRST+7, {{BASE_60_00_03, 0x3F}, SC_100, }}, //--> 00 .. 64 High Depth (0..100)
{KAT_CC_FX_FIRST+8, {{BASE_60_00_03, 0x3C}, SC_NONE_80, }}, //--> 00 .. 50 Low Pre-Delay (0.0..40ms)
{KAT_CC_FX_FIRST+9, {{BASE_60_00_03, 0x40}, SC_NONE_80, }}, //--> 00 .. 50 High Pre-Delay (0.0..40ms)
{KAT_CC_FX_FIRST+10,{{BASE_60_00_03, 0x39}, SC_NONE_16, }}, //--> 00 .. 10 XOver freq 100Hz-4kHz*/
};

[snhirsch]

That looks like fun, Robert. In my early years with computers I coded Apple 2 device drivers in 6502 assembly language. There you had a bit under 2k of program space, so every byte counted. Sometimes I miss working to tight constraints. It can really get you thinking outside the box.

[snhirsch]

In terms of functionality, I really want and need a GUI controller with save/recall function that's also able to respond to MIDI. Kind of like FxFlooboard and PatchLoader in one. If I'm at practice and the patch I worked on all week isn't cutting it, I'd like to be able to twiddle controls real-time and persist the new state. My bridge code is really only covering the save/recall piece. At present I have to switch USB cables to edit and it's a PITA.

[Beanow]

@CodeSmart63 Yeah I worried that would be the case for any micro controller situation. Aside from cherry picking some meticulously optimized source files or using data like https://github.com/katana-dev/docs/blob/master/data/tsl-map-1.0.0.csv for auto-generated code you can't afford to include the whole library.

On top of that the specific goals for the MIDX's don't seem to involve much that is subject to heavy change, regarding the Katana at least.

But I still wanted to flip the question, do you see potential for anything worth sourcing coming out of a library like this?

[Beanow]

@snhirsch that is an interesting idea. What kind of physical setup are we talking about here? I'm assuming you would add a laptop/phone to the equation here rather than hook the beaglebone up to a monitor, keyboard and mouse. And where would edits go? Straight to 60 00? The beaglebone patch files on disk? Both?

So far I found you can do quite a lot with forwarding MIDI messages through virtual ports, like in mididings. Especially floorboard (as opposed to tone studio) does not complaint as long as traffic eventually ends up at the Katana and eventually gets responses.

[snhirsch]

@Beanow My ideal physical setup would probably be a tablet, as I don't want to carry a laptop to gigs. Alternately, I suppose I could use a laptop to dial in and persist patches at home or in the practice room, then use software on the Beaglebone to recall presets during performance.

For Plan A, I can envision a smaller Android tablet in a holder above the amp control panel. The tablet will need at least two USB ports, but I suppose this could be provided using a powered hub.

[Beanow]

@snhirsch typically the app model for software doesn't give a lot of scripting capabilities. You'll probably want to reach out to condor to see if it would be something to add to his app. http://www.vguitarforums.com/smf/index.php?topic=20234.0

[Beanow]

In #2 I decided to change to Go for the library's language. And to only export higher-level functionality. This definitely rules out micro controllers as this will pull in the Go runtime environment and standard library. But will make writing great code for the juicy problems a lot easier.

Meaning things like 7bit type conversions and the checksum algo are too low level to warrant exposing through the library. Instead you can expect features like local patch manipulation, tsl compression, serializing back and forth between tsl, protobuf and sysex, etc.

[gumtown]

Have you looked at Qt5 ?
http://doc.qt.io/qt-5/

Here is a link to the FxFloorBoard source which uses Qt5
https://sourceforge.net/projects/fxfloorboard/files/KatanaFxFloorBoard/Katana_fxfb_source.zip/download

[Beanow]

Sure have, I think it sits in between C and Go as choices. It makes a lot of things easier and less error prone. But it doesn't go all the way like Go. Still have to do memory management, still not very doable to write parts of the library as type-safe pure functional code, testing and documenting isn't as simple as go, etc. So I figured if I'm spending time to learn something more in depth Go would be better in the long run.