#94

From looking at the code “multi” is the only allocation mode (mode 3) which pays any attention to the midi channel (mapping channels 1-4), the others should respond to notes on any midi channel. This seems like weird behavior you’re seeing but I’m not really at all familiar with the Ansible midi code or with the various ways controllers decide to differ in their messaging – I seem to recall once having a drum pad that would send a note on and then a note off a full second later, and I’ve got a controller that only ever sends F#5 and transmits the pitch entirely on pitch wheel messages. Not being (remotely) fluent in Max I’m not !00% on what I’m looking at here, but does there seem like anything’s weird about the message stream? There are also a fair number of WebMIDI monitors that run in Chrome: 1, 2

Bummer, I took another pass at this a little while ago to try more stuff when the drive connects, but still have a mix of drives that work fine and others that suddenly hit some error.

There is a variable in flash declared for it, and it looks at the stored value to determine what mode to load when a midi device plugs in, but I’m not spotting where this actually gets saved? Seems like a bug, will look at that.

1 Like
#95

Hmmm.

With all that it should be working.

I’ve made a video here showing what I’m doing/getting in case something weird is going on, but I’m definitely sending the right messages as per Max and midimonitor.com, but no response in modes 3/4.

I also show that modes 1/2 work as intended, and that note length is determined by how long you “hold” the stick down per press.

I also dug up a couple more thumb drives (FAT32 formatted and all) and still no joy. From the ‘saving presets’ procedure, I just plug in the thumb drive, and then press (not long press) key1 and the LED should go white?

#96

Key 2 (on the right) to save, and yes the LED will turn white to indicate that it’s armed. Press Key 2 again to start the save and the white LED should start blinking. If there is an error during saving both the white and orange LEDs will turn on. You’ll need to have reflashed the firmware to a 2.0.0 beta to do this, which wipes existing presets for all apps, but it is possible to extract a raw hex dump from a module running 1.6.1 which I can convert to a JSON file.

1 Like
#97

Hmm, maybe that’s it? I remember upgrading to the most recent build I found a couple of weeks ago, but that may very well have been 1.6.1 which is the most recent release on the github.

Is the 2.0.0 on the github? Does it need to be built/compiled?

#98

It is still in beta, you can get a built .hex file of the latest beta build from the first post in the Ansible Development and Beta Firmware Discussion thread.

1 Like
#99

Ok, getting some action finally, although still not successfully gotten the presets off.

I flashed to 2.0.0 and can get to the step where the LED goes white when I press key2, but each of the thumb drives I’ve tried only goes orange/white when I press key2 again (instead of flashing and writing the preset). I’ll try some more drives later.

Does the formatting matter (e.g. FAT32) or is it just picky about the brand/make of the drive?

#100

Oh yeah, there is definitely only code for handling FAT. I should probably mention this in the docs, but I honestly didn’t think anything around was formatting flash drives with non-FAT32 filesystems? I guess if you need a >32GB partition? Goes to show that I have probably not bought a flash drive in a decade. I don’t know what other issues there might be but the code for interacting with the disk is quite similar to what Teletype does for saving scenes to disk. If you have a specific model or two of FAT32 formatted disk that doesn’t work I can maybe buy a couple and try to troubleshoot.

#101

Ok, after trying a bunch, I actually managed to get one of the ones that didn’t work before working.

I exported the presets and confirmed that the default values were set (and therefore should be working with my MIDI mapping), but to rule problems out I tried to change them to other values to retest with diff values on the BopPad. (I used Atom as my editor on a Mac)

I wasn’t actually able to reload the edited preset though, as after the flashing orange LED (more on this below) it goes to a combo white/orange LED “error” state.

If I check what’s on the drive after that, an ansible-backup.bin was created, so the process got at least that far.

I then re-exported the preset to see if the process did still work (and threw up an error for other reasons) and the results were odd. If I check for the "fixed" values (the only things I changed), the values were set to:

"fixed": {"notes": "24240000", "cc": "10111213"}

Which are the default CC values, but the notes are set to something other than the default values and what I tried to set them to. (I tried to set it to: "fixed": {"notes": "26242F2A", "cc": "1234"}). Would these have been default values in an older firmware maybe?

/////////////////////////////////////////////////////////////////////////////////////////////////////////

Ok, I tried it again and it still threw up an error (white/orange after some blinking orange when loading from the drive), but after exporting the loaded preset, I do see the correct values now:

"fixed": {"notes": "26242F2A", "cc": "1234"}

If I plug my BopPad in, I actually see one gate firing (MIDI note 36), so something is happening in MODE4 now at least, but nothing else happens.

But I don’t know if the error corrupted the preset file in other ways and/or if something else is going on.

In terms of the fickleness of the USB drive, if it works at all, should it work? (as in, is the error I’m getting when loading to do with something else) or should I try to hunt down another thumb drive that this process works with?

/////////////////////////////////////////////////////////////////////////////////////////////////////////
One thing that confused me is that there is a typo in the documentation:

To load presets:

  • Press KEY 1. The ORANGE LED turns on to indicate that the device is armed for loading.
  • Press the MODE key to cancel, or press KEY 2 again to read a ansible-presets.json file from the disk into Ansible’s flash storage.

I think the second bullet point should say “press KEY 1 again”, as that seems to actually trigger the flashing orange LED and process.

#102

Another small update. I found a little baggy of thumb drives and tried a bunch of them. I got at least 5 of them “working” in that I was able to backup the preset, edit it, and almost load it back onto the ansible. Every single one of them flashes the orange LED for about 20sec, then goes to the white/orange “error” LED at the end of that process.

To rule out the possibility of my computer/editing/atom was doing anything to the file, I backed up the preset to a thumb drive, pulled it out, put it back in, and tried to load what I just saved and…that seemed to work fine . (the first time I pulled it out and put it back in it gave me a white/orange error when I pressed KEY1, so I pulled it out)

So maybe my computer and/or Atom is doing something weird to the file?

Here is the edited preset file I’m trying to upload to it:
ansible-preset.json.zip (9.2 KB)

#103

Sorry about the trouble, looks like a couple things went wrong, probably none of them is the disk or the editor. Here is a file that I think should work (with CCs = 1, 2, 3, 4): ansible-preset.json.zip (8.9 KB) One is that part of the Earthsea state incorrectly was configured with a buffer length of 0, so any backups this build was generating were malformed! I fixed this maybe day before yesterday and gave me deja vu, I think I must have accidentally reintroduced this in some merge I did. Sadly this means your firmware will need to be reflashed (current build as of this writing: 49013cd) if you want to save backups. The other issue is that the CCs need to be written as a 4-byte hex value, so 01020304 instead of 1234.

When an error is encountered the preset load will bail out completely, since the load going bad somewhere could mean that illegal values have been loaded into flash, or just that one app only partially loaded which could be confusing. This is what ansible-backup.bin is for – this is a raw dump of the contents of flash state prior to opening the JSON file, so that Ansible can reload its previous settings in the case of an error. So seeing the values unchanged from the defaults when you save the file again is expected.

For some apps you can save a lot of time (and in this case avoid bugs in unrelated parts of the backup) by only saving/loading state for a single app, which is accessed by holding the mode key while inserting the disk. Midi apps have so little saved state compared to Kria/Earthsea that the save/load would be basically instant. However this works for Grid and Arc apps because those keep running when you disconnect the controller, which doesn’t really make any sense for the midi modes. Need to think about a possible UI for accessing this.

If it can’t mount the drive, I would expect you to get an error indicator immediately. Unfortunately I have also seen some instances where I think the disk had some bad sectors or was otherwise old and flakey where it would try to load for quite a while before encountering an error.

I should mention that if one doesn’t mind taking a soldering iron to their Ansible (the pads are tinned already, super simple job), with a right-angle surface mount IDC header and a 5V FTDI/USB cable it is possible to get a fair amount of diagnostic info off the module’s UART for errors during the disk load:

> usb disk locked
mounted nav id 00000000
> making binary backup
> binary backup done
> starting usb disk load
!! bad buffer len: 00000002(expected 00000004)
!! bad property value: cc
!! bad property value: fixed
!! bad property value: midi_standard
!! bad property value: apps
> FAILED! total bytes read from disk: 0010F795
> total tokens processed: 00029303
failed on token type 00000003 that spans 0000002C - 00000030
> contents of read buffer:

": 0, "fixed": {"notes": "26242F2A", "cc": "1234"}, "shift": -32
                                            ^--^


> disk backup malformed
> usb disk load done
> restoring binary backup
> usb disk unlocked

!! filesystem error code: 00000000

Thanks a bunch for beta testing and for finding the docs typo!

1 Like
//// pictures of our sound-making machines ////
#104

Great, that works now!

Real fun to play with, and works with my default BopPad setup now too.

The "1234" did seem odd to be, but since I don’t work with hex much, I trusted Max’s conversion of int->hex, which gave me single character versions.

Is there a way to set a SLEW for the CV outputs while in a MIDI mode?

#105

Looks like you can do it from Teletype with MID.SLEW, this is an op that takes a single parameter. You could also edit the JSON file:

"midi_standard": {"clock_period": ..., "slew": 0}

The way it’s applied depends on the mode:

I’ve also thought about adding an ANS.SLEW x s op to let you change the current slew value per track, no matter what mode Ansible is in. The trouble with ANS.x apps is that they generally have to be sent to all the I2C addresses Ansible uses, which seems like potentially a fair amount of I2C traffic and latency.

#106

I don’t have a Teletype, so editing the JSON is my only option.

Is the "slew" value set in samples or milliseconds? (or something else?)

Also, not sure if I’m reading the code correctly, but does the switch/case statement mean that only the POLY and MULTI modes have slew applied? (and not FIXED)

#107

Yes, should be milliseconds.

It appears that that’s right, in Mono mode pressure and mod CCs get a 5ms slew, in fixed no slew is applied. This would need a little rework to do what you want probably but not too bad.

1 Like
#108

Ah snap.

Yeah, it would be great if it was possible to apply (the same) slew to all of the MIDI modes as a single param.

I only really noticed as the pressure data from the BopPad is real… steppy sounding.

#109

If I can remember my thinking way back when the reason that FIXED didn’t obey slew (or have any by default) was that I was operating under the assumption folks using FIXED were likely using it for some non-voiced / computer driven purpose. …I have nothing against changing that.

UPDATE: …looking at the code I’m reminded of another reason it is the way it is. IIRC the various “slew” commands which were available on the teletype at the time (like for the JF voice modes) tended to target pitch CV. The other reason was probably avoiding the complexity with keeping track of different slew values per output per mode.

#110

Yeah, in thinking about it further, the slew wouldn’t be useful for certain outputs (e.g. pitch/note), so I can just apply a slew externally the “pressure” output from the BopPad if needed.

(in an ideal, but impractical, world, there would be a per-CVx output slew in FIXED mode)

#112

Is there any script available for Ansible that let you use ARC to control 4 LFOs?-

#113

Are you thinking of Cycles?

1 Like
#114