#55

Amazing! Thank you so much for this. I’ve given it a go and it works perfectly. I think it makes a lot of sense when building up a scale. Once nice trick is to set all the notes to unison, and then work up from the bottom, starting with temporary notes and then locking them in and allowing the notes above to jump as a result. Another pleasing effect is to have an arpeggio running and then use the temporary scale change to make the notes’ pitches to switch order.

I think it makes perfect sense to have this as a live setting and not saved with the scale or pattern state. I kind of think that changing the scale should reset the adjustments, but I can also see a use for keeping them in place when patterns change…

Thanks again for the incredible turnaround from vague idea to actually being able to use it. Awesome!

5 Likes
#56

As the Varigate was my go to sequencer for awhile, I can’t help but wonder if some of its tricks could be implemented while we’re in the process of development of Kria. There is a possibility on the Varigate 8+ to set a randomization range, for example I can set the range from 0-5 for Ratcheting per step/trigger, and when that step is triggered, I will get a random number of ratchets from 0-5. This random range can be set for all the parameters, from trigger, to trigger width, etc.

And stray lit LEDs, this has been there since I received my grid and ansible, where in certain screens, with certain notes on, there are some stray LEDs lit. I don’t really understand it or if this is a bug in the original firmware, anyone also experiencing this?

1 Like
#57

This was such a wonderful suggestion, it’s so much fun to play scale degrees with this new behavior! I agree with keeping this as a live setting and I’d support clearing adjustments once scales have been changed. I think that would keep the cognitive load low and encourage improv scale changes.

I haven’t tested the 4-step-brightness mode yet because I found a bug in loading preset files, which @csboling is working on :+1:

#58

Just posted a new build (9cee10a) with:

  • fix for Kria state not being saved/loaded to disk! oops! I think this may have affected builds from the past couple days.
  • changing a scale will reset scale adjustments for all steps, but changing a pattern will not
  • fixes for bugs identified by @kbit in PM – note division page was unresponsive, ratchet division page was changing the wrong thing when note div sync + div sync were on

Thanks again to everybody for all the beta testing!

5 Likes
#60

Hello,
to be honest, I completely forgot I had to modify the hex file…
I will do one of these evenings…
Unfortunately I am in the middle of a big life change event so I can only do just a few bits of beta testing but I am loving all the ideas everyone is proposing.

Thanks for doing all this work.

#61

I’ve been thinking about this off and on but don’t have a rock solid UI picture of it yet. I’m unsure of both how the input should work and how the randomization range should be displayed once it’s programmed. With notes, I think it would be great if you could program multiple note choices for a single note step, Parc-style, and as the loop visits that step it would select one. But as a further wrinkle I think it would be awesome if you could select a direction mode for how it should cycle through notes, i.e. select the next note via forward/reverse/triangle/drunk/random strategies. I find myself drawn to a lot of sequences where I want to change the selected note each time the loop comes around, but then I want to go play with other parameters, so I wind up copy-pasting the loop over to another couple pattern slots and make tiny alterations to each one. But adding this kind of complexity maybe has a lot of consequences for cognitive load, storage space, UI design, … I’m especially interested in what people think the UI for parameter range/randomization features ought to act like.

I have noticed this! I believe I also encountered this when first learning Kria before I had made any firmware changes, and originally thought it was some feature I had activated by mistake. I’m not sure how it happens and I haven’t been able to reproduce it consistently enough to properly debug these spooooky ghost keys. Though I do sometimes wish I could peek at a different parameter page from the one I’m working on, especially when trying to place a parameter change on just the right step.

1 Like
#62

these recent updates are phenomenal, thank you @csboling!

there has been mention of this previously, but i think all the extra kria-counterpoint is bringing the issue to greater attention: ansible CV output channel-to-channel accuracy isn’t perfect.

with the new JSON import/export plumbing (stunned at this accomplishment!) i’m wondering if the presence of a textfile with scale tunings would be a good solution?

  • bugfix: ch-to-ch accuracy
  • bonus feature: weird microtuned scales! (?)

i’m not sure what sort of tuning granularity we’re looking for? i’d almost suggest just correction for octaves, and then have a macro generate the 12 tones between? or it’d be not too much trouble (and perhaps more interesting generally) to have the full map exposed?

11 Likes
#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