christofmuc / knobkraft-orm Goto Github PK

This seems to be a known issue with JUCE, in that you need to force it to rescan the list of devices available to the system. Here is a thread on this:

https://forum.juce.com/t/listenning-midi-devices-plug-unplug-and-plug-devices-from-computer-again/35886

Hi,

Thanks for all your work on this. From the short time I've had using it, I think it's going to be a really useful tool for my Rev2. I encountered a small problem building on Linux though.

On Ubuntu 19.10 Eoan, when building from commit f831268 I get the following error:

...snip...
[ 78%] Linking CXX shared module pytschirp.cpython-37m-x86_64-linux-gnu.so
lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:153
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-9/README.Bugs> for instructions.
lto-wrapper: fatal error: /usr/bin/c++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[2]: *** [pytschirp/CMakeFiles/pytschirp.dir/build.make:232: pytschirp/pytschirp.cpython-37m-x86_64-linux-gnu.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:1021: pytschirp/CMakeFiles/pytschirp.dir/all] Error 2
make: *** [Makefile:133: all] Error 2

I can work around it prefixing LDFLAGS="--disable-lto" to cmake:

LDFLAGS="--disable-lto" cmake -S . -B builds && cmake --build builds

Unfortunately I don't have enough expertise with these build tools to figure out a permanent fix. I'm happy to do some testing for you if that helps. I'm using cmake 3.16.6 (self compiled as the distro version is too old at 3.13.4) and c++ 9.2.1 (distro package).

Thanks!

Suggestion:

1. find duplicate patches (happened due to wrong imports), best case by sysex comparison, worst case by name
2. enable deletion from the main window on a per patch basis by either right click or long touch, or delete all but one (ideally not the favorite one)

This is bad because you cannot blank out the name of the patch, or volatile bits that you want to ignore when fingerprinting the patch.

The function is called "filterVoiceRelevantData" in the Synth base class, and would need to be exposed to the GenericAdaption's python interface.

Hi!
When I use "Import edit buffer from synth" I get no patch in library.
Am I missing something?

This is not really a bug, but a workflow issue - if you create a new patch based on any other patch in the OB-6, and import it into the computer, it will still have the original name. Because the OB-6 has no display for it, and no way to rename it, that can be quite suprising.

What should I do? If there is already a patch with that name, offer to rename? Offer to call it "BasicProgram"? That's the name you get when you start with an init patch on the OB-6.

Question is how to test.

Building yourself is always an option, it should not be too hard. I probably should enhance the build instructions.

Currently, there is no single place to choose which device is set to be the master clock, and I actually have multiple cases. Sometimes I want the drum machine to do it, sometimes the looper pedal. Sometimes both are turned off and I want the synth to be the master.

This can easily cause multiple MIDI clocks to be turned on at the same time, causing havoc.

Idea: Show a screen with a list of all synths that can generate a MIDI clock, and allow to turn them on and off, respectively do a Radio button that turns one on and all others off.

Also allow to set clock to slave mode. Not sure about the start/stop behavior.

Also measure on and show on which MIDI interface a clock is received. That would be important to know if the turn on/off worked, or if some other device is sending clock.

This is a bit problematic with MIDI patch bays like the Motu midi express XT, as that has a single "sync interface" that collects all clocks from all interfaces, and you cannot detect which port actually receives the clock.

It should have a clock measurement built in to show the clock received.

It could have a clock message translation function for the Boss RC-300 so I can finally slave that unit.

What I need is a MIDIClockCapability, with the following functions:

• List supported clock modes
• change supported clock mode
• get current supported clock mode

I think the clock modes are probably easy and everywhere the same. Maximum I think:

• Master (Internal)
• Slave (External)
• Off
• Slave no Start/Stop
• Slave passthrough

Importing from synth fails if you import more than one bank at a time, it hangs at 99% after the first bank. This happens if selecting more than one bank, or using import all button.

Importing individual banks works more reliably, but still occasionally hangs at 99%. If you cancel the import, the data is not there, if you start the import again, the app crashes and closes.

Windows 10 1903 - 18362.1082
MOTU MIDI Express XT with latest drivers.
Virus OS 4.9

Importing from synth fails if you import more than one bank at a time, it hangs at 99% after the first bank. This happens if selecting more than one bank, or using import all button.

This is from issue #16

Some synths - e.g. the Virus C - allow tagging/categorizing patches in synth. When such a synth is supported, it should be used to create the tag and do not (?) auto tag with the names.

not clear when this is happening, I am sure this is a regression.

Complex: Let the user choose the order of synths.
Less complex: Sort them alphabetically.

Could remember which synth was selected last.
Could allow to set "startup" synth. Conflicts with "select last synth".

Reported in GearSlutz: https://www.gearslutz.com/board/showpost.php?p=15057748&postcount=38

I need to test myself, it definitely worked at some point in time.

Information needed would be mode of connectivity (USB/DIN MIDI) and the MIDI log after the download failed.

The Orm is currently meant to be used as a computer-based patch librarian, for easy backup, quick sifting through patch banks and easy management of own patches stored in synths.

It is not (yet) a bank manager.

For that, we'd need a UI that allows the user to sort patches (drag and drop), and build new lists of patches from the overall library. Then those could be sent to the synth as a patch bank.

Technically easy (the MIDI communication and patch uploads etc. are there), but the UI needs some thinking as it should be self-explanatory and efficient at the same time, and ideally also work on future tablet versions.

If somebody has a recommendation of a program that did a very good solution, I'd be happy to have a look.

This is part of ticket #26.

More details there.

We need a way to multi-select patches in the grid, and perform an operation on exactly those. E.g. delete, or export.

If I set View to Scale 100%, I can just about cope with the font size used for the menus, because I mostly know what they say, but I need to squint, or use an on-screen magnifier, to make out the patch names properly. If I set View to Scale 125%, the font for the menus gets bigger, which is nice, but not essential, but the patch names shrink to being almost totally unreadable.

I'm using a 1360x768 LCD screen, and also system fonts set to 125%, but possibly that setting isn't used by Orm.

Here's a couple of screen shots, with the log at the bottom reduced to the minimum size, by dragging the top downwards. The first is View Scale 100%, the second is 125%. Your eyes are probably better than mine, so you may be able to read patch names at 100% fairly well, but I'm struggling with it.

100%

125%

Would it be possible to reassign some of the unused space for showing the patch names larger? E.g. the gaps around the buttons, and the borders inside them?

Linux app store: https://flatpak.org/

E.g. There also needs to be a CLEAR or RESET button for the tag filters section.

Source: https://www.gearslutz.com/board/music-computers/1334549-sounddiver-2021-a.html

"Seems like ALL is listing patches Alphabetically but as several sections starting over."

From https://www.gearslutz.com/board/showpost.php?p=15175240&postcount=21

I need to think about logical ways to sort the patches - by import, by name, by tag, ...? Where to put the UI for that?

You seem to be able to edit it, but it changes back?

I made a start on making a new adaptation, reading through the new adaptations manual. I got to the part where it said to change the name function, but it didn't say whether it was okay to change the file name, and if Orm would recognize it if I did.

I tried renaming the python file, and that worked, but it seems like that should have been in the documentation.

Personally, I find it harder to follow a manual if it's raising questions for me that it doesn't answer, because I end up thinking about that instead of paying attention.

FWIW, Korg have quietly dropped all support for Windows 7, even though support for Windows 10 isn't working properly, for some of their synths. So, there may be a greater need for Orm, and other non-official sysex librarians.

"I wish when I reopen the app, it knew what size I had pulled the window to. It resets the size every time I open and I have to redo that."

From https://www.gearslutz.com/board/showpost.php?p=15175240&postcount=21

E.g. "Strings" might be preferred over the generic "Pads"

Source: https://www.gearslutz.com/board/showpost.php?p=15175240&postcount=21

Well known, I had worked on that in April 2020, but it got somehow overruled by other work and then pushed down in priority.

your mentioning of touch screen friendly programming brought me to the idea of using my laptop (connect via LAN to the mio10 over rtpmidi, mio connected via usb to main pc) for touch screen friendly patch selection while playing the p12. For that to happen I need to keep the db/config in sync. Where is the db? And what other files should I need to keep in sync?

I made an experiment, and it seems there is easily enough information in the sysex that when you have a learning data set (have manually or via name assigned categories to a couple of patches), you can train a classifier and then have the rest of the patches automatically assigned into these clusters.

First experiements on the Matrix 1000 showed this works. Kind of.

Not sure about multi-assignments - a cluster algorithm always will choose just one class, but we can actually deal with uncertainty.

Main challenge to productization will be that your python environment will need to contain scikit-learn and other huge python libraries, which is not a friendly install for everybody.

After choosing auto detect, on the first run after installation, KnobKraftOrm crashed, so I tried to do it from the Setup menu.

Prophet 12 Module was on the list of MIDI devices, so I chose that for the source and destination. Pressing "Re-check connectivity" then failed - see attached.

I tried it with the MIDI channel set to Omni, and to 1. Both failed.

I then tried Auto Detect again, which didn't crash this time, but also failed to detect it. See attached.

I own an Elektra One ( https://electra.one https://github.com/martinpavlas/electra.one https://forum.electra.one ) and imho it might makes sense to figure if you can work together.
Possible scenarios:

1. use Elektra as a device to remote control knobcraft (e.g. patch selection)
2. use knobcraft for Elektra preset management (can also be offline!)
3. sysex patch management and parsing: I don't know exactly what might come out of it, but I have a feeling that it might be good things :-)
   I really really like that both of your ways of working (open source, using github etc). I will make the same suggestion at their github

When importing already known patches, there is a mechanism to refresh the metadata of the patch.

In the beginning, this was only the name. The name was overwritten only if it was "better" than before. That was determined by checking if the name was a "default name", like Init Voice or 01. This mechanism however only works for patches that have a stored name capability and have implemented the default name function properly.

For other patches without stored name capabiliy, it is currently ignored if you have set a better database name. E.g. on the Kawai K3, if you rename a patch, and then reimport it, the name is reset to "01" or whatever program place that patch was stored at.

For some synths, you don't have any patch names stored in the patch, but have external lists with patch names. How would those get imported into the Orm? Read a CSV file, a JSON file, a .midnam file?

"BRASS category needs to be a color and not light grey, if Dark grey is the color of the current selection. Almost think the current selection should be something easier to see but maybe not. "

Source: https://www.gearslutz.com/board/music-computers/1334549-sounddiver-2021-a.html

Strange issue with multi-bank import on Virus C: "In the pull down, I can see All Patches and the last bank I imported as choices, but ALL also only contains the last bank imported and not every bank I've imported. So somehow the Database isn't adding and I can't see anyway to Save it. "

From https://www.gearslutz.com/board/showpost.php?p=15175240&postcount=21

"In ALL bank view, I wish you could select the page number. That's not working. I have to scroll through them all to get back to page 1."

From https://www.gearslutz.com/board/showpost.php?p=15175240&postcount=21

This could be useful for synths without any patch names (Korg DW8000, MKS80), as it might be hard to remember which patch was whitch. Maybe the preview of the waveform will help accelerate finding a specific one, or you could even distinguish patch categories?

Could be simply implemented via sending the patch, playing a MIDI note, and then recording whatever comes into a specific audio interface.

Could also be used to audition a patch without having to connect the synth - just play the WAV file.

Could use the patch category to play a specific note sequence? Like a bass line, a slow patch, a lead phrase?

If only a single bit is changed, two patches no longer have the same fingerprint and are considered different.

This is not really helpful if you have just created a variant of a patch, and might want to compare multiple variants.

I could define a metric that allows for patch similarity search - not on perception (different story), but on the bitvector. Could use edit distance or something similar.

How to implement this in the SQL database?

Windows Defender and BitDefender both report the app is using the microphone.

On Windows, the installer copies the adaptions into a user document folder, as the original expectation was that the user can create new adaption scripts and might want to put them there.

As there is no installer on Linux, the Orm does not find the adaption files and therefore shows nothing. I don't even know exactly which folder the JUCE code would deem to be the correct one - I hope the home directory. Should I bundle the shipped with adaptions as binary? Then the user cannot override them.

Most elegantly I ship them as binary and the executable copies them out when it doesn't find them there. But then I would overwrite them? How do I check that the version present is the one I would write out? So I need to make a backup copy? Advantage: That would work on Windows and Mac as well.

Hi!
I have a problem - can't rename the patch
It says it got renamed but in fact its not

If you use a smaller laptop screen like with 768 rows, the layout is pretty ugly and you cannot see the log screen. This should be fixed.

Thanks to Iulian for reporting this - the Matrix 1000 multi bank import was behaving somewhat timing dependent.

Reason for this: It does send out some 80 dummy split patches for backward compatibility with the Matrix 6/6R, and I was not waiting long enough before sending out the next bank dump request.

The correct way to implement this is to switch the strategy from bankdumpcapability to streamloadcapability, as you send one request command to the M1000, and it answers with 181 messages of different types.

I wonder if this is the same for all firmware versions, as the documentation in the Internet states it sends out 50 split patches, but in reality it sends out 0x50 == 80 split patches. This is a bug only in the documentation? Or are some firmware versions sending out different numbers of split patches?

The Matrix 6 manual clearly states that it has 50 (0-49) split patches, which makes sense given it has 100 single patches.

I fear 0x50 split patches is a bug in the Tauntek firmware?

Hi!
Great software you've made 😄

Looking at youtube video when one imports a library of patches stored in a single syx file, it then simple to identify that import by looking at title "Imported from file Rev2_Programs_v1.0.syx (512)".

In my case I've downloaded a lot of syx from this project http://refacedx.martintarenskeen.nl/
They are presented like this

$ ls Reface-PSS480/
00_synth_brass.syx       12_jazz_guitar.syx    24_music_box.syx           36_acoustic_guitar.syx  48_ice_block.syx         60_steel_drum_2.syx        72_12string_guitar.syx   84_tuba.syx               96_human_chorus.syx
01_jazz_organ.syx        13_rock_guitar_1.syx  25_honky-tonk_piano.syx    37_harp.syx             49_reed_organ.syx        61_chimes.syx              73_classic_guitar.syx    85_alto_sax.syx           97_kazoo.syx
02_pipe_organ_1.syx      14_wood_bass_1.syx    26_toy_piano.syx           38_picked_bass.syx      50_electronic_organ.syx  62_tubular_bells.syx       74_mandolin.syx          86_bass_clarinet.syx      98_musical_saw.syx
03_piano_1.syx           15_trumpet.syx        27_transistor_organ.syx    39_slap_bass.syx        51_pipe_organ_2.syx      63_hand_bell.syx           75_sitar.syx             87_bassoon.syx            99_sine_wave.syx
04_harpsichord_1.syx     16_trombone.syx       28_tremolo_organ.syx       40_ukulele.syx          52_piano_2.syx           64_carillon.syx            76_koto.syx              88_recorder.syx
05_electric_piano_1.syx  17_horn.syx           29_small_church_organ.syx  41_strings.syx          53_harpsichord_2.syx     65_synth_tom.syx           77_shamisen.syx          89_ocarina.syx
06_celesta.syx           18_soprano_sax.syx    30_funky_clavi.syx         42_alpenhorn.syx        54_electric_piano_2.syx  66_timpani.syx             78_jamisen.syx           90_piccolo.syx
07_vibraphone.syx        19_clarinet.syx       31_accordion.syx           43_bagpipe.syx          55_glass_celesta.syx     67_violin_2.syx            79_mute_bass.syx         91_samba_whistle.syx
08_marimba_1.syx         20_flute.syx          32_glockenspiel.syx        44_mute_trumpet.syx     56_bandoneon.syx         68_rock_guitar_2.syx       80_electric_bass.syx     92_brass_ensemble.syx
09_steel_drum_1.syx      21_oboe.syx           33_hawaiian_guitar.syx     45_tenor_sax.syx        57_street_organ.syx      69_tremolo_guitar.syx      81_wood_bass_2.syx       93_woodwind_ensemble.syx
10_violin_1.syx          22_harmonica.syx      34_banjo.syx               46_jug.syx              58_synth_bass.syx        70_rock_guitar_3.syx       82_electric_trumpet.syx  94_human_voice_1.syx
11_cello.syx             23_whistle.syx        35_bowed_bass.syx          47_panflute.syx         59_marimba_2.syx         71_pedal_steel_guitar.syx  83_wow_trumpet.syx       95_human_voice_2.syx

As you see here each instrument is stored in an individual syx file. So I'm forced to use bulk import to import all PSS480 patches. And here is the trouble. If I'll do imports per each device from that site, they all will be unnamed like "Bulk import 05/18/20 at 19:17:06 (182)" and it will be hard to get what that import was about.

Is it possible to add ability to rename imports or maybe just put folder name in the naming?

Thanks!

This came up multiple times, now with JUCE 6 it should be easier as it was with the old CMake system.

Question would be what features are possible in a DAW, and what makes sense.

Would you create one KnobKraft per project, or one per Track? Would the track be then just the patch selection? How to detect the synth?

I think I don't know enough about DAWs to understand the use case yet.

Either a dedicated command, or a multi-selection of banks (with easy "all").

Came up in https://forum.sequential.com/index.php/topic,4327.0.html

Hi,

is the matrix 6 keyboard supported? My matrix 6 is not recognized at all - or I do domething wrong.
Version 1.20 does not start.

Running on Windows 10.
Regards,
Stratos

This came from a YouTube comment:

"Is it possible to store selfmade presets from the Prophet on Mac with this software, so i can send it to a friend?"

Very good question! As of now, the only way would be to share your database of all patches with him, but I can easily add a function to store the patches as a sysex file to either import into his Orm, or to send directly to the prophet. I'll add an enhancement idea to my list. I think the easiest way would be to just export all current patches into individual files (one .syx file per patch) - those would be edit buffer files that you can send to the synth without having to worry about overwriting any content or any bank. Thank you!

This came up here: https://www.gearslutz.com/board/showpost.php?p=15058108&postcount=40

Probably hide is not good enough... if you could delete a whole import, you would have kind of an undo. Also you could offer single delete and multi-delete.

Deleting a whole database probably isn't needed when you habe File New database... because you can simply overwrite the existing one then.

An undocumented feature: If the synth supports detailed parameters (like the Rev2), you can actually type a python expression into the name search advanced filter. If you prefix the name search with an exclamation mark, the current patch will be a dictionary called p.

The syntax matches the pytschirp syntax.

Example:

!p["LPF Audio Mod"].get()!=0

Will search for patches that use the Rev2's audio mod feature for the low pass filter.

The names of the parameters currently can be seen best in the Patch Diff dialog. If there are no parameters shown in the patch diff, the synth does not support detailed parameters yet.

To productize: currently, the search is run in memory, so I would need to load all patches first, not just a single page, and then run the search. Exploding that information into the SQL database probably is overkill for a desktop application, that would make most sense in a client/server scenario.

Also, the parameters would need to be documented, e.g. an autocomplete of parameter name.

The syntax is ugly with the p["..."].get(), these characteres could go away and be added automatically. Or I improve pytschirp to allow better syntax.

Tried to do an Alesis Andromeda A6 adaptation, failed :-)

1. knobcraft now crashes directly after launching, event viewer shows:
   "
   Faulting application name: KnobKraftOrm.exe, version: 0.0.0.0, time stamp: 0x5fde4975
   Faulting module name: ucrtbase.dll, version: 10.0.19041.546, time stamp: 0x43cbc11d
   Exception code: 0xc0000409
   Fault offset: 0x000000000007287e
   Faulting process id: 0x2a08
   Faulting application start time: 0x01d6d7be4f85311b
   Faulting application path: C:\Users\Markus\AppData\Local\Programs\KnobKraftOrm\KnobKraftOrm.exe
   Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
   Report Id: bb80b332-04ca-48bc-be90-f49a71019471
   Faulting package full name:
   Faulting package-relative application ID:
   "

2. already failed before, first I didn't understand if "def createDeviceDetectMessage(channel):" is for the request or the answer, after I figured out that it was for the request and subsequently put it "return [0xF0 0x7E 0x7F 0x06 0x01 0xF7]" it still failed to load the adaptation with an error in that specific line.
   The manual for the A6 states; "The A6 responds to the Universal Device Inquiry message < F0 7E 7F 06 01 F7 >"

3. How do I treat the manufacturer ID if it is more than one? Manual says "00 00 0E" is for Alesis.
   In Midi-OX the A6 responds to F0 7E 7F 06 01 F7 with F0 7E 7F 06 02 00 00 0E 1D 00 00 00 30 31 34 30 F7

Currently, you can select only one masterkeyboard and then have different modes on which synth to route the MIDI to.

If there is already routing, KnobKraft won't help you much.

What I envision:

Show a list of all synths which have a keyboard. Show and allow to change which MIDI channel they send on.
Show a list of all synths/expanders which take MIDI notes. Show and allow to change which MIDI channel they receive on.

As the devices are already detected by the Orm, it could then offer a button "play this expander from this synth", making them match the MIDI channel and route the MIDI through the computer. Alternatively, if you already have a standalone MIDI patch bay like I have with the Motu midi express XT, you don't need the routing feature, just matching the MIDI channels suffices.