VGuitar Forums

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 6 7 [8]   Go Down

Author Topic: Gumtown's Katana FxFloorBoard Editor  (Read 6544 times)

0 Members and 1 Guest are viewing this topic.

gumtown

  • Global Moderator
  • Senior Member
  • *****
  • Rating: 195
  • Offline Offline
  • Posts: 4670
Re: Gumtown's Katana FxFloorBoard Editor
« Reply #175 on: June 09, 2017, 06:19:37 AM »

Hey Gummie,
Do think you could limit the traffic a bit unless you're not connected directly to the "KATANA" MIDI IN/OUT?
With MIDX-20 V2 it's possible to hot-swap the Katana Bridge on/off allowing your Floorboard to talk to the Katana through the MIDX (via UM-ONE) while tweaking the sounds and then enable the bridge again (via MIDX Assistant PC software)  to make the footswitches etc. working. It's like an iteration before everything falls into place. I've just used my SoftStep2 to control the amp via my bridge and your Floorboard to tweak settings, without swapping any cables. Great combo.

However the Floorboard has problems getting the patch dumps from the Katana through the MIDX because the MIDX buffers can't hold the amount of data you request through it. I tried to increase buffers but won't help, there's not enough SRAM. I'm pretty sure it would work gracefully if you requested smaller portions and waited for it until requesting a new block. Ideally for the MIDX you would not exceed 310 bytes bulks.

You think it's possible?

limiting the data time sent between F0~F7 syx data blocks to the Katana is easy to implement,
but receiving Katana patch data into the editor would require quite some code changes, breaking the data into 10 block requests at timed intervals.
Easy enough for the editor to identify the MIDX20 device by name (assuming it has a unique device name).
Logged
Free "GR-55 FloorBoard" editor software from http://sourceforge.net/projects/grfloorboard/

CodeSmart

  • Senior Member
  • ****
  • Rating: 50
  • Offline Offline
  • Posts: 1250
  • Trying to stay healthy and learn about electronics
    • primovasound.com
Re: Gumtown's Katana FxFloorBoard Editor
« Reply #176 on: June 09, 2017, 11:31:38 AM »

limiting the data time sent between F0~F7 syx data blocks to the Katana is easy to implement,
but receiving Katana patch data into the editor would require quite some code changes, breaking the data into 10 block requests at timed intervals.
Easy enough for the editor to identify the MIDX20 device by name (assuming it has a unique device name).

The current MIDX-20 hardware does not have an unique device name. It's not a USB device at all. You have to connect it using a USB to MIDI converter cable. So it's the name of the USB cable you see. So you can only see it's NOT a Katana. Perhaps better to follow Beanow's suggestion and add a checkbox for "limited traffic". Maybe you don't have to go down all the way to <310 bytes as buffer is only filled gradually due to the difference in outgoing and incoming speed. But I cannot give you a number. It's working ok with the GP-10 Floorboard, with occasional re-tries. I don't know how large the patch blocks are in that program...
Logged
Got more gear than I need...and I like it!

Beanow

  • Senior Member
  • ****
  • Rating: 3
  • Offline Offline
  • Posts: 101
Re: Gumtown's Katana FxFloorBoard Editor
« Reply #177 on: June 13, 2017, 05:18:18 AM »

but receiving Katana patch data into the editor would require quite some code changes, breaking the data into 10 block requests at timed intervals.

I had a skim through your patch receiving code, void bankTreeList::updatePatch(QString replyMsg) being the crux of it if I located this correctly.
That does look like you've set things up to be transactional, marking the device as busy while receiving.

With the library I've gone a whole different approach, reading the sysex header to see if it should write to the local patch object. You just forward the data whenever you like and it will start mapping it. Signature being apply_message_to_patch(patchReference, byteArrayPointer, byteArrayLength). Which I plan to update with a Katana layer so it routes to CH1-4 and Panel for you. Just feed it sysex from F0 to F7, or any other raw midi data and let it ignore that.

Since you're using signals a lot to pass updates around, it would be a great candidate to set up this unidirectional dataflow.

So if I can work out how you do your reading and writing operations after that, perhaps I can experiment with fitting in lib-katana to make this change easier.
For the stompboxes you read scalar values by address it looks like, using midi.xml data to get a scaling function. That should be easy and I've already done this in Go.
How you do changes though I'm a bit confused. Looks like the new value itself is passed directly using signals and sysxIO sends the value to the Katana, is that right?

Edit:
SysxIO::setFileSource seems to update your local data as well as sending a message to the Katana. While the valueChanged signal bubbles up primarily to have a single handler and to display the change on the top panel. At the same time the core read function seems to be SysxIO::getSourceValue. So it looks like turning this class into a wrapper for the lib-katana calls would be the way to go.
« Last Edit: June 13, 2017, 07:14:46 AM by Beanow »
Logged

Beanow

  • Senior Member
  • ****
  • Rating: 3
  • Offline Offline
  • Posts: 101
Re: Gumtown's Katana FxFloorBoard Editor
« Reply #178 on: June 14, 2017, 09:40:42 AM »

After some testing I was able to move small bits of the code to use lib-katana for the local patch state. However moving to it entirely is going to be quite a task. A lot of functions use direct access to the internally encoded state, particularly using SysxIO::getFileSource. Trying to modify that I was soon smashed with a mountain of compile errors and segfaults. Which means getting things to be functionally equivalent would be a huge refactoring already. Not to mention using lib-katana to support different data flows.

Both switching to lib-katana and switching to a different architecture, it may be faster to salvage what remains and build the engine from scratch in a fork. Being able to run lib-katana from the Floorboard code though does give me a much better idea of what the library needs to mature and what functionality to cover though. So I will probably experiment with this approach for a while.

In other words don't hold your breath for me to have a solution for the throttling issue anytime soon.
Logged
Pages: 1 ... 6 7 [8]   Go Up