#63

If you’re looking for something to work within the idea of a 12 tone scale but with a little more granularity, I’d suggest looking at the 22 Shruti intervals:

More in-depth reading of how these are derived can be found here: http://22shruti.com/research_topics_list.asp

I’ve used Teletype to convert KR.CV to just intonation based on these intervals and it allows for some beautiful harmonic relationships while not straying very far from 12 tone theory.

3 Likes
#64

I think being able to load arbitrary tuning tables from disk would be pretty awesome! For matching CV outputs, I’m not sure what a typical procedure is, it seems like repeatedly tweaking tunings in a text file and loading them up until all the CV outputs match might be a time consuming way to try to hone in on the right values. So maybe you would want some kind of UI to dial in the pitch corrections? Anybody have any favorite grid UIs for tuning, or for defining microtonal scales? Maybe there’s a simple way to calculate the right adjustments based on a couple voltage readings or something though. I think lots more interesting customization options would also open up with the JSON files if I ever get around to writing a PC app for manipulating them – this could be a friendlier way of managing non-ET tuning tables, but still might not be able to account for mismatched CV outputs.

2 Likes
#65

Hello,

there is an inherent mismatch between ansible channels, meaning that if I play the same note on all channels, it does differ in the voltage that could be read as output by any channel.
I believe @tehn was talking about this.
I did measure it some time ago and he was so kind to send me a replacement output board that did not fix completely the issue but it is close enough.
I believe this might be fixed on the software side?

Also I want to ask you if you can send me a better explanation on how to install your python script to convert the hex to json file.
I did not manage to do this yesterday
I have 3.7.3 version of Python installed on Mac OSX EL Capitan.

Thanks

#66

Does this procedure work? Namely:

git clone https://github.com/monome/ansible
cd ansible/tools/flash_tools
python -m venv .
source Scripts/activate
pip install -r requirements.pip
python main.py extract --version 1.6.1 ansible.hex --out ansible-preset.json

Let me know where you run into issues and I can update the readme. If you prefer you can also PM the hex file to me and I’ll convert it for you. I have not added the suggested option yet for indicating what grid_varibrightness you want, so that will have to be edited into the JSON file by hand – this would require a bit of script rework that I’ve been putting off to play with Kria.

To clarify the usage of the Python script:

  • if you are updating from one Ansible beta to another, or from future releases > 1.6.1, it should not generally be needed. The ansible-preset.json file can be saved by Ansible on one firmware and then loaded after you update, or vice-versa – this forward/backward compatibility is one major motivation for going to the trouble of using a JSON representation rather than a binary dump.
  • the primary use case for the Python script is to carry over presets saved on a currently released version (<= 1.6.1) to the new version, so that from that point on you can use JSON files to manage presets.
  • providing the firmware version that the hex file is from is required and must be exact so that the script knows the memory layout of the hex file. Currently I only have layouts for 1.6.1 and 1.6.1 + Earthsea. If you know have an older version, its layout will need to be added to the Python program, please let me know when you PM a hex file. If you’re not sure, but you know it’s a release version, you may be able to figure it out from the release changelog, otherwise I can try and do some reverse engineering - knowing an estimated version range would help. Trying to convert from a hex file and specifying an incorrect version might not work at all, or might have out-of-bounds values that could break the functionality of Ansible apps. I will do my best to sanity check any backups that I convert but this is also a component in need of some beta testing and the converter program might have its own bugs.
3 Likes
#67

I’ve been having a blast playing with the temporary scale change feature to create melodies and chords on the fly. Im creating new scales so easily that I find myself wanting to save them.

So, could a copy/paste function on the scale screen work? Maybe a gesture like holding the current scale position to copy, then long press a second scale position to paste; and any temporary changes made on the scale while the copy/paste procedure is being performed are written into the new scale as well.

I could see some issue with this if the temporary change position is below the previous scale interval. Perhaps a saturating limit can be imposed in that situation, resulting in a duplicatiom of the higher pitch in the new scale to keep it in tune?

2 Likes
#68

ME TOO <3 <3 <3 it so much!!!

#69

Thanks a lot for your hard work. The new features sound amazing!

I’d like to try your latest build, but no luck so far. A few months ago I updated my Ansible to 1.6.1, so dfu-programmer is installed on my Mac.

When I downloaded the 1.6.1 ZIP file I got a ansible.hex file and the update-firmware.command file. When I’m downloading the ZIP file from your link I get the complete folder structure, but no hex file, so that doesn’t work.

Sorry, I don’t know nothing about using Github. Could you please tell me how to upgrade to your build? (I don’t have presets I want to transfer.)

Thanks a lot!

#70

sounds amazing. if possible, and you have the means, would you be able to post a quick vid with an example? I have the newest firmware installed but I’m not quite clear on how this is implemented. Thanks.

#71

Hello,
thanks for the explanation but I cannot run the venv module in python.
When I write python -m venv . it says “/usr/bin/python: No module named venv”.
So I assume it is some problem with python then.

/UPDATE/ I have to use python3 and pip3 commands instead of python and pip, now I am stuck on the last commend to convert the file.

Anyway, thanks also for the explanation regarding the use of json but Am I right that I need to upload the prest file to be able to use a 4 step varibright monome?
Does this mean that I will always have to create a preset file and modify it when there is a new version of the software?

This is something that would be really important to understand

#72

Simple enough that a video shouldn’t be necessary! On the scale page your intervals are choose with the glyph on the right hand side. To alter the note of the scale without changing any of the other notes, hold the square that is active then press another in the same row to shift it. You should see a lighter grid to indicate the temporary position. If you single tap the original square once again it will shift back to normal. If you single tap any other key you will alter the scale as the original behavior would.

#73

i think I get it now. Will try to give it a spin when I’m back at home. thanks!

#74

1.6.1 is the previous/existing release. It does not contain the changes described in this thread, which is for prerelease betas. To try those you want the ansible.hex file uploaded as an attachment to the first post in this thread – it sounds like maybe you’re working with the 1.6.1 zip file from the Github releases page? I’ve only uploaded hex files so far. update-firmware.command should probably also be included but currently is not – once you have ansible.hex the commands you want are:

dfu-programmer at32uc3b0512 erase
dfu-programmer at32uc3b0512 flash ansible.hex --suppress-bootloader-mem
dfu-programmer at32uc3b0512 start

which is the same as what’s in update-firmware.command. (Or it should be – I think older update-firmware files might contain at32uc3b0256, which might work fine or might give an error now that the code uses more memory.)

The default firmware assumes 16-step varibrightness, and the only way to change this is from the JSON file, so this change will need to be made in order to be saved into Ansible’s flash. After that, this setting can be treated like part of your presets: insert a USB disk and do the disk save procedure before you flash a new firmware, then load your presets off the disk after updating. This sounds annoying / easy to forget, I’ll find a spot to add this setting to the grid interface somewhere.

From earlier in the thread it sounds like you are already on a beta firmware, so you don’t need to run the Python script to create an ansible-preset.json file unless you just want to – you can just do the USB disk save procedure, then edit the file on the USB disk with your computer, then load the preset back up on Ansible. In fact if you are working with an ansible.hex backed up from any of the betas I’ve posted, rather than from the official 1.6.1 release, this could be why the Python script is encountering an error (most typically this manifests as something along the lines of “expected bool but value 5 was found” or something, but other errors are possible).

I have posted a new build (afb85ec) which contains a prototype grid interface for arbitrary reassignment of Ansible’s tuning table. This is not very polished but I wanted to post it to get some feedback, especially because it sounded like @tehn was about to start working on this. So first some caveats/questions/observations:

  • I apologize that I have not tested this with 4 brightness levels. I agree that having to re-initialize the varibrightness setting via the JSON file is pretty annoying, I think the next thing I’m going to do is make this programmable somewhere on the grid interface. This should have the side effect of making it much easier to check out different varibrightnesses while developing a UI.
  • If you calibrate your CV outputs, since KR.CV reads the current DAC value, you will read different KR.CV values from Teletype for two different outputs even though the voltages they output are equal. This suggests maybe a need for a KR.N op to get the calculated pitch in “semitones” that Kria is using, (i.e. octave + octave shift + scale note + scale note shift + alt note… am I missing any offsets?), so that you can differentiate the programmed pitch from the actual output voltage. Note that such an op would not be able to read the exact pitch value while an Ansible CV is slewing.
  • How should interpolation between octaves work? Should we fit a line to ensure that the entire output range is mapped linearly, or is it useful to be able to correct for nonlinearities? The fit I’m using is just a dumb piecewise linear interpolation between octaves. This has the downside of being nonlinear, so it’s possible to have weird pitch tracking behavior depending on how you program the octaves. It has the upside of being nonlinear! This lets you do some fun stuff like have a tuning table which gets lower in pitch in the middle and higher at either end, or use one or more tracks of Kria as a really flexible if mind-bending CV sequencer, or whatever. Possibly multiple interpolation methods are needed? It seems like maybe this interface could be made to even support arbitrary interpolation waypoints, where octaves would be the default, using a long-press or something.
  • Completely by accident, if you have a Kria sequence running when you switch to tuning mode, Kria is still running, and you can re-tune a running track on the fly, or play the tuning interface to accompany your sequence microtonally. Frickin’ rad. You can quick mute some tracks if you want to tune them without the sequence running. You can also switch back to Kria or to other apps to experiment with the tuning you have programmed, but tuning tables are not saved until you explicitly save them, so if you like what you’ve got make sure you go back to the tuning page to long-press the save button before powering off.
  • This is maybe kind of a complicated interface! There’s a lot of data it’s possible to manipulate. I’ve attempted to keep it so that routine tasks are fairly accessible but in-depth tweaking is still available. I’m planning to follow up with a step-by-step guide for calibrating Ansible using this UI. I think it may also be possible to devise a Teletype scene that partially or completely automates this procedure using the ANS.G ops…

Which brings us to the (other) fun part:

Tuning interface

Enter Kria. Hold Key 2 (config). The Scale page key from Kria remains highlighted with Key 2 held. Press it to enter tuning mode. You can let go of Key 2 now to exit tuning mode, and tap Key 2 again at any time to go back to Kria.

The top four rows, as in Kria’s trigger page, correspond to tracks, with only the center 12 keys highlighted to represent the 12 steps in the tuning table between two “octaves”. All tracks and therefore all triggers are on by default. The playing note in each track is highlighted, and the currently tuning row is highlighted slightly brighter than the other rows. By default all notes being tuned are the same (Ansible’s lowest note slot, 0V by default). You can change which note slot is selected and playing from each track by touching the corresponding key in the top 4 rows. If you touch a different track than the currently tuning track, that track becomes selected for tuning. If you touch the active note in the track that is currently tuning, the corresponding trigger output goes low, so you can mute one or more voices if you are tuning by ear and patching the trigger outputs to your VCAs. Note that a note slot may be currently selected for tuning even though the corresponding trigger output is off – probably this should still be highlighted somehow but currently is not.

The bottom row provides keys for increasing (keys on the right) or decreasing (keys on the left) the value that will be sent to the DAC to play the currently selected note slot. From the center out these are +/- 1, 2, 4, 8, … +/- 128 on the outermost keys. Some of these should probably be un-highlighted when you can’t step that far because you’d hit the minimum/maximum DAC value.

The row above the bottom row is a quick reference for the DAC value the currently selected note slot is set to. As the DAC value increases, the leftmost key will get brighter, then it will turn off and the next key over will get brighter, etc, mapping the full CV range over 16*varibrightness steps. You can touch a key on this row to jump to a DAC value, note that this will result in the key to the left of the key you pressed at maximum brightness, because otherwise all the LEDs in this row would be off and it might be tough to see where you’d switched to.

The left side of the row above this selects which “octave” you have selected, just meaning a group of 12 note slots.

The right side of this row (third from the bottom) is for load/save functionality.

  • The key to the left which is separate from the other two is the panic key – press it to restore your saved tuning table from flash, long-press it to go back to the factory default equal temperament tuning table. This long press does not save anything, so you can quick press the key again to go back to the tuning table you have saved, if that’s different from the factory default.
  • The first key on the right is for interpolating the tuning table between octave values. Quick press it to do a piecewise-linear fit between the values programmed for each octave. Long press it to fit between octaves and then save.
  • The key furthest to the right can be long-pressed to save all note slots with their tunings exactly as currently programmed.
5 Likes
#75

i’m a visual kinda guy, so I think I figured it out. for once I “may” have something to contribute around here instead of my constant mooching :slight_smile: video essentially shows everything kbit described in text.

3 Likes
#76

@csboling: any chance that if we select 1 or more extra notes per note in the scale, that we can get Kria to randomly select between them as well?

#77

Is the tuning mode added in the latest version (20/06/2019)?

Replying to the convo on Ratcheting and selecting a range:

Would it be a possible to do it by holding the button for where you want the first ratchet then press the second button to indicate the range (a bit like hope we set loops). And the ratchet sub-division selection would work and be applied to all the ratchets in that column.

Make sense?

#78

I downloaded the “ansible.hex” file attached to your fist post. But where should I put it? The folder structure included in your ZIP file includes an scr folder, which contains the “update-firmware.command”. Should I drop your “ansible.hex” file into the same folder – or into the “ansible-master” folder?

Thanks a lot!

#79

this is great— if you’re interested in pushing forward on this please do— i have a billion other things on my list :slight_smile:

have the recent features stabilized? when shall we call this 2.0? (i’m figuring a version bump given the inclusion of earthsea)

3 Likes
#80

Yes, should be – I just double checked that I uploaded the right file.

I think this is pretty intuitive, I was thinking out loud (in my usual verbose manner) about this idea in this post, but haven’t tried implementing anything like this yet.

I think if you have dfu-programmer installed on Mac you should be able to put the ansible.hex file anywhere and then run the commands from that folder in a terminal. On Windows I put them in the same folder where I have dfu-programmer.exe. ansible.hex is the only file you should really need. If you downloaded a 1.6.1 zip file and extracted it, I think you should be able to replace the hex file in that extracted folder with the one attached to this thread, and then double clicking the update-firmware.command should hopefully work?

I think things that have gone into master so far are pretty stable. Things I’ve currently got in the works:

  • Need a way to set the desired varibrightness through the grid UI, rather than just from the JSON file. This I think should go in the release.
  • Sounds like subdivision selection on the ratchet page is maybe confusing as-is, I’ve got some ideas for making that less surprising for basic usage.
  • I would also like to include tuning mode since I agree that DAC calibration goes well with the other features.

That said there are always more little things to tweak and I realize you’re trying to start shipping a batch of new Ansibles here in a couple weeks, so unless more bugs are found I think I’m fairly happy with the existing functionality and we can always do another release fairly soon. So I think I’m probably good with calling it after, say, whatever I can get done this weekend.

8 Likes
#81

Yeah, tbh I don’t find it particularly intuitive, I don’t understand why their steps stay after removing a ratchet. I just expected the entirety of the ratchet to be gone when I disable a ratchet.
Maybe that doesn’t make sense? On the other hand that’s how all my sequencers work.

Also doing triplets doesn’t actually seem to be doing triplets, at least it’s not doing what I’m expecting. Need to try it out a bit more to determine if it’s me misunderstanding something or if it doesn’t work correctly.

#82

I guess with this implementation they probably are not on the beat, but shifted by the length of one tripled?

I have not tried the latest features yet, but from just reading I get a bit worried if the UI is still intuitive and easy to use/play. Hopefully Kria does not get overloaded for some quite specialized use cases as random ranges for features that already are very filigrane like ratchet and note offset.

BTW, I always thought Kria already had an official feature for altering single scale notes without shifting the rest of the scale.I rarely used it - has it gone lost somewhere on the way to the current firmware?

At the latest beta I can’t manage to disconnect notes, triggers and tracks. All config graphs are unlit but still everything is bound together. And the UI ist messed up when the loop wraps around the right end of the grid on note page.

I think this is to make it easier to program one extra “ratchet” trigger for example on substep four of possible five without actual having the five substeps triggered. I have to admit that this is one of the more esoteric features which I am afraid that they make Kria less intuitive and easy to use and I would be fine with just a simple 1 to 4 ratchet.

I guess one would need to be quite smart for intentionally using all this to program interesting sequences. Otherwise it would just come out as the usual pseudo random quantized sequence music. There is nothing wrong with this I am just not sure how heavy featured that would have to be.

2 Likes