Both JF mode and i2c buttons are brightly lit, as are the 5 above i2c. JF outputs volume is up all the way, and the physical outputs mapped to the same voices are also working.
very strange. the only other thing i can think of - is there anything running on crow that might also be sending to just friends?
will try to test jf+crow+es set up this weekend.
I don’t think so! I had that same thought, and tried running a few different scripts on crow to see if it was conflicting at all—different scripts didn’t seem to affect the lack of functionality.
Basic question - If I run this firmware on Ansible am I still able to switch into the stock Ansible apps or would I need to reinstall the original Ansible firmware to be able to access Kria, Meadowphysics, stock Earthsea, etc.?
it replaces the original firmware completely, so, yes, to switch back to the original apps you will need to reinstall the original firmware.
partial success. i’m able to reproduce the issue with ansible running polyES + jf + crow setup.
i was able to get it working for a short while while crow was still running the initial first script by running druid and executing:
i tested with orca’s heart first and the above fixed the issue. what’s strange though is that switching OH to a different i2c device and back (which also tells jf to set mode to 1) made it stop working again, and repeating the above didn’t work until i powercycled.
with polyES same thing - executing the above fixed the issue, but then turning i2c leader mode off and back on again would result in no sound again.
i then tried updating to the latest crow firmware and now i can’t get it to work using the above method. the good news is - it’s definitely solvable, just need to figure out what’s going on. need to see what crow is doing under the hood.
Could i briefly inform myself here what function the 3 shape knobs of og ES would take with this firmware please? I dont really get it. The original shape function never appealed to me that much, are the knobs used for sth else here?
if you run polyES on any module that has knobs (such as ES), they will be automatically assigned to mod buses starting from the first one. you can use mod buses to control various parameters, such as octave and transpose, and if you use any i2c devices you can also control volume and, in case of txo, waveform, attack and decay.
to select which parameters mod buses control (and the range for each parameter) use this page: https://github.com/scanner-darkly/polyearthsea/wiki/output-parameters-and-modulation
you can also use arc, shnth or a MIDI controller as sources for mod buses. for arc and shnth simply connect them to the USB port and they’ll be automatically assigned. for MIDI, arm recording, then move the knobs you want to use, then disarm.
remember, you can control multiple parameters with the same mod bus, so you could assign one knob to change waveform on 4 TXo voices, for instance!
Still over my head for now (more variables than needed for my case)
Simplification (i have no i2c, no txo and not coming), og ES with grid, i could set each of the 3 knobs to change one of the mod bus functions, like octave change and set it/store it that way through power cycles.
“Module” refers to og ES in this case and volume (and therefore accentuated variables) change would be off the table!?
Hope i got that right, sounds very useful indeed.
yes, module here can be earthsea or white whale or ansible or meadowphysics. no, it is not possible to change volume if you use module CV/gate outputs, it only sends pitch and gate data to those.
you don’t need to assign knobs to mod buses, that’s done automatically. you will need to assign mod buses to parameters you want to control, the link i posted explains how. these assignments will be stored when you store a preset.
While here, do you see any issue in using PolyES with grid and anisble or trilogy with a doepfer 192-2 for midi conversion?
Mostly asking bco this:
“Important notes: The CV voltage has to be present at the rising edge of the gate signal. It seems that for some sequencers on the market that’s not true. If a sequencer generates the CV after the rising edge of the gate the A-192-2 will output apparently wrong Midi data because an “old” CV is taken to generate the Midi data. But that’s a problem of the sequencer, not the A-192-2. To fix this problem the A-192-2 would have to “wait” a couple of milliseconds (depending upon the delay between Gate and CV of the sequencer in question) before the CV is measured. But this would degrade the timing because then the Midi data are sent later then the rising edge of the gate signal. Please clarify if you want to use the A-192-2 with a sequencer if the CV/gate timing is correct (for the A-155 that applies of course), i.e. please ask the manufacturer of the sequencer in question if the CV is generated before the Gate and not the other way round.”
Thanks again! And i hope you do well!
polyES sends gates after it sets pitch CVs, but it will still take some time for CVs to “settle” when their values change (from my limited hardware understanding), so it is possible that you will need to use an additional module to delay the gates. the only way to say for sure is to try it i’m afraid.
Will try my luck i suppose.
On meadowphysics the 8 outs correspond to 4 cv 4 gate like ansible?
no, meadowphysics can output gates only, so you get 8 voices of gates (could be used as a trigger sequencer)
Need to ask one of my annoying cheap ass questions again, sorry in advance : )
I used to use ansible Poly ES just fine for my applications with a 64 greyscale in the past.
I want to make sure if i assume correct the 40h will have the same dimension of compatibility or is there really sth that will get in the way between 40h and Ansible?
i don’t have a 40h so can’t say for sure but according to this thread it should work. in terms of how the app itself will behave on a non varibright grid - it should be the same experience as using a greyscale.
Sry to bother again but this detailed (module dependent) info doesnt seem to be documented anywhere.
With PolyES on original ES the 3 CVs are 3 note polyphonic or rather paraphonic bc there is only one Gate output. Correct?
Midi will be still 3 note poly/para!?
what is sent to module outputs is determined by how they are mapped on the voice assignment page.
by default, module outputs are mapped to notes (pitch and gate): notes from voice #1 will be sent to CV/gate output #1, notes from voice #2 will be sent to CV/gate output #2 etc etc.
it will use whatever outputs are available. on modules that don’t have the equal number of CV and gate outputs you might only get partial note information (pitch only or gate only). on meadowphysics you get 8 voices - but only gates. on white whale you get 2 full voices (pitch and gate) and 2 voices with pitch only. on earthsea you get 1 full voice (pitch and gate) and 3 voices with pitch only.
instead of outputting notes you can also configure module outputs to output CV voltage based on the key (note number) or x/y coordinates of the note pressed. this is a convenient way to use polyES to also provide modulation for something like filter cutoff. as an example, you could set up filter key tracking this way:
- map voice 1 notes (pitch/gate) to output 1
- map voice 1 key to output 2
- connect CV output 2 to filter cutoff
you could then map voice 2
x coordinate to output 3 and
y coordinate to output 4, now if you switch to voice 2 your keyboard becomes an x/y pad controller with CVs output on 3&4.
it does not output MIDI.
The modulations via grid /ES wouldnt be so important for me but even by your information i cant really see if its safe to assume i could play a 3 voice (3 osc) Paraphonic Synth that has 3x CV IN (1 for each Osc) but only one Gate since its paraphonic not poly?
I forgot ES wasnt designed as a poly module unlike Ansible so i oversaw this.
Would my application work out fine?
With midi i meant Midi to Cv wich im sure it does, just not sure if only monophonic or in the same way as i assume above.
yes, by default you will get 4 voices on earthsea - pitches for all 4 but gate for just one.