Posts by kpahuitsing

Although the PROFILER supports USB-HUBs, it does not support hosting multiple USB-MIDI devices simultaneously at this moment.

several options here:

• use an external MIDI merger (on TRS/DIN side) -> connect Chocolate + backing-track via MIDI merger to USB interface to Player
• use a USB interface with multiple inputs and a built-in internal merger -> connect Chocolate + backing-track via built-in merger of that interface to USB Player
• maybe use the 'Chocolate-plus' ? (the specs of that unit show a USB-HOST mode: in theory -> connect Player to Chocolate's host, and connect backing-track via existing USB MIDI cable to Player's host)
• use a stand-alone USB host which can host multiple USB devices *and* accept TRS/DIN MIDI -> connect Player + Chocolate as USB device to that host, and your backing-track player via TRS/DIN

Gelstronic : good to hear it works now, thanks for the feedback!

we've identified and fixed the issue, it will be fixed in the upcoming OS.

of course the KPA will *not* be destroyed from (unexpected) power-outage.

but please do not tamper with the inside of the Profiler. This is something for support. That battery is there to keep the real-time clock running and nothing more: even a dead or removed battery will not cause the Profiler to fail booting.

simple / trivial things to double-check:

- did you actually plug the cable thoroughly into the KPA again? (we've had several cases where the mains cable just wasn't pressed thoroughly enough into the KPA)

- did you try with another mains-cable?

in the end: best is to contact support

Quote from Ruefus

I know nothing will change and I respect that. Please respect that I find it stupid.

yes: I respect your opinion

yes: you're correct: the casual user really should find another controller in that case, because that controller(/implementation) is broken.

The KPP doesn't have to fix misbehaving devices : in an ideal world the KPP would be robust against all garbage it is being thrown at.. and we do our best to get it as robust as possible. But in this case: a device declares as USB MIDI device, but actually is not capable of receiving (some) MIDI data? How should the KPP know, and cope with that?

Anyway: we will NOT implement an ActiveSense OFF option. A connected (USB)MIDI device should be capable of _receiving_ that message (and it can simply ignore it : just as you correctly did with your custom device)

(by the way: in regular (DIN) MIDI, active-sensing hasn't been any problem since the 80's ..

oh: and also by the way: you could declare your custom controller to be a MIDI-OUT device only (so remove the USB descriptors for MIDI-IN) .. that way the KPP wouldn't need to send any messages which would be discarded anyway

sorry to confirm: but unfortunately the problem has not been solved yet Don't know if we are *far* from the solution, but it isn't working as it should at this moment.

hmm... sorry to hear that it still wasn't fixed in 12.0.1

so: in the current release : 12.0.3 we've implemented an even more strict mechanism to avoid those pesky spontaneous movements... during our tests they're gone now. We would love to hear from you if this solves the problems for you too.

(Google translate:)

Hinweis: Die Verbindung von 2 PROFILERs miteinander kann ohne ein USB-<->DIN-MIDI-Kabel erfolgen. Du kannst eine direkte Verbindung mit einem USB-A-B-Kabel herstellen (= dasselbe Kabel, das man zum Anschließen eines PROFILERs an einen Computer verwenden würden).

In diesem Fall benötigst Du also keinen USB-A-zu-MIDI-Kabel

- unpacking 'incorrectly' : for example virusscanner destroying the kaos.bin file after extraction

- copying to 'root' ... sometimes this is unclear to customers where to actually copy to

- 6 flashing LEDs : reboot/ contact support

did you observe that a firmware update actually took place at all? (there should be a yellow progressbar during update, and updating takes a while)

in your specific case: maybe the system doesn't recognize the update as being 'different' and skips the updating process? You could try to use another version first : for example first try to update with a release version, and then use a beta version (or the other way around)

this isn't difficult at all for *a lot* of customers who do not have any problems with it.

.. but unfortunately you are experiencing non-typical problems at this moment : maybe it has something to do with your specific unit (hardware issue?), maybe it has something to do with the way you're downloading the data, maybe it has something to do with the way you're unpacking the data, maybe it has something to do with the way you write to the USB stick, maybe it has someth... etc. etc.

contact support and they will work this out together with you.

so: the fact that in-fact it *did* change something, indicates that there is something fishy going on with your setup / procedure

did you besides using a new stick, actually re-download and re-unpack ?

best is to contact the support : they will help you out further.

4x LED red = something went wrong during firmware update, possible causes:

• broken/bad USB stick
• broken/bad download of ZIP file
• broken/bad unzip of the ZIP file data (kaos.bin extraction)
• broken/bad write to USB stick by host OS

you could try to re-download the update, re-unZIP, and use another USB stick (basically re-do the update procedure with a fresh download and a fresh stick)

Hi carloswalter / AppleTreeChen / JCW308 ,

In public beta OS 12.0.1, we've implemented a fix which should solve this problem. If you want, you can test out that version and check if it solves your problems.

Quote from Bistro79

by the way: that image shows that you're using a 128G stick, not a 256G stick.

meanwhile the Sandisk Ultra Eco 256G version has arrived over here for testing (https://www.amazon.nl/dp/B0B8X7DX8D)

1. the 256G version works right out of the box : no problems here -> so the PROFILER can handle at least this 'modern' big stick without problems , and there is not per se a structural problem with big sticks
2. formatting this 256G stick like Bistro79 did, simply with the default settings of Windows will result in a unsupported format stick (exFAT)
3. when inserted into the PROFILER this way the PROFILER will ask to confirm formatting (there is a pop-up dialog which asks 'Are you sure? - USB stick needs to be formatted' --> so this is as intended, because the PROFILER can't recognize exFAT
4. when pressing 'yes' to format it takes aaaages to complete, and there isn't much UI feedback to the user : about 6.5 minutes (so this could be improved on PROFILER's side; it looks like the PROFILER is hung-up; after the formatting is done the only indication that it succeeded is that the tap blinkin commences.. the user has to press 'exit' before continuing)
5. after the stick has successfully been formatted by the PROFILER everything works fine : the stick has it's full capacity of 256G
6. If you really want to format the stick on a Windows machine for use with the PROFILER you'll be needing a 3th party tool (tested for example with 'guiformat.exe by Ridgecrop Consultants' ) -> be sure to format as FAT32LBA and the PROFILER will accept the stick.

conclusion:

a) at least this Sandisk Ultra Ecu 256G works as it should: no problems over here - another stick which does work fine!

b) do not bother to format the stick yourself: just use a USB stick right out of the box

and what happens if you let the PROFILER format the 256G one?

we've ordered the Sandisk green 256G ourselves.. and will have a look at that one too

We can reproduce the issue, but unfortunately a fix is not at the horizon

so: it has our attention, we're investigating, but we don't have a fix yet.

that screen shows a 16G stick.. but you have a problem with a 256G stick; correct? how was that 256G stick formatted?

Quote from Bistro79

.... But I formatted them myself with Fat32 / 4069 Bytes, not used out of the box.

which OS did you use to format the stick that way? and how exactly were the settings you used? (would like to test that too)

nice! thanks for testing, good to know