yeah i’m afraid to do this properly would require reworking the voice assignment page which is already pretty complex, so hard to justify doing it for what is a very limited use case.

So the just type poly functionality would be given with trilogy ES just as with Ansible right?
What will happen with the physical cv outs when using just type, would those be able to trigger sth else in parallel?

If i manage to decide for 128 grid but monobright for a start (lets see where the update goes), what limitation would i face by not having varibright?

I realise that the pattern playback field of polyES is allready missing for 64 so kind of makes sense to chain my 64 with a second one for 128 at least, afaik that can be done (40h).

any supported i2c devices (just friends, txo, er-301) will work regardless of which module you’re running polyES on.

what happens with the physical outputs is up to you - it depends on how you map it. it’s completely flexible. you can map different voices to i2c and physical, you can map same voices, you can send a voice to physical output 1, er-301 port 4, just friends output 3 etc etc

re: monobright - really hard to tell. some functionality might be difficult to use with non vb.

i don’t think that’s supported, unless there is some hardware mod i’m not aware of.

1 Like

Sry to bother but my setup is right now far from finished to try…need a lot of soldering.

I am not sure i understood voice allocation of trilogy ES running PolyES completely.

Lets say i play voice 1 wich has gate, i play voice 2 while gate is still high, if i remove my finger from voice 2, it wont stop unless voice 1 sends gate off, same for a 3rd and 4th voice?

Beside cumberosme and not intuitive gate delay, there isnt much i can do in trickery to overcome this?

it depends on how many voices you have enabled for that pattern and how they are assigned.

voice allocation will use whatever voices are available for that pattern. when a new note is played, it will use the first available voice. if all voices are already in use, it will steal from the earliest note.

let’s say you have voice 1 and voice 2 enabled for the current pattern, and both are assigned to output 1. you play first note - the gate goes high. you play the second note - since you have voice 2 enabled, it will go to that, but since voice 2 is also using output 1 it will send pitch to CV output 1 and it will continue holding the gate high. if you release note 2 it will set gate to low, even though voice 1 note is still on - it doesn’t do a special check in this case to see if any other voices assigned to the same output are still active. could be done but it’s not how it works right now - and it wouldn’t make sense to implement something like it, since with just one output having multiple voices doesn’t make sense, you would just have one voice assigned to a pattern and sent to output 1.

1 Like

Totaly apreciate your patience i ve to say.

I was assuming the 2nd and a potential 3rd voice would or should be assigned and patched through the several cv outs. I am not sure if in your example how note 1 would still play when note 2 is triggered since one CV output can not be duophonic?

it wouldn’t - once you play note 2 the CV output will output pitch for note 2.

for normal polyphonic application you would have multiple voices each assigned to its own output. so then you play note 1, it goes to output 1, you play note 2 (while note 1 is still active) - it goes to output 2 and so on. and if you play a note and all of the voices are already being used, it will steal from the earliest note.

And the gate of out 1 is kind of a master gate, wich means as long out 1 is high, the notes will play sustained wich could only be altered via envelope?

Think i got it

overlapped notes sent to the same output will result in the gate being held high - envelopes won’t help since it won’t get retriggered. this was discussed a while ago, the solution would be introducing a gap but then you get a delay, so it’s not a proper solution.

Nono… seperate outs was my thinking.

if you have separate outputs then you’ll just get notes sent to different outputs, there is no “master” gate.

Hi @scanner_darkly!

I’ve just updated my Ansible to the PolyEarthsea alt firmware, and I think it’s amazing! I’ve dreamt so many times of having a fast, simple and multitrack sequencer like this, so thank’s a lot!
The only issue that I’m having is that I can not control the Ansible module from my Teletype. I have a I2C cable connected from my TT to the Ansible. With the new firmware I have the 6th button on the rightmost column off, which seems to left the Ansible in follower mode. I then type " TR.P 5" in Teletype and nothing happens on the Ansible. Am I doing something Wrong? The TT-Ansible comunication was working fine before the update …

TR.P and CV ops are only supported when ansible original firmware is running in teletype mode - this mode is not supported on polyES (it only supports ES teletype ops).

Thanks @scanner_darkly!

What I’m trying to do right now is to convert the grid response on the Ansible to match each button to a semitone in a continuosly way. In other words, instead of having this formula (X + (7-Y) * 5 - 1) to calculate the semitone of each button, I would like to have a (X + (7-Y) * 16 - 1). By doing this I can have broader range on the CV outs of the Ansible. I’ve seen the files in the PolyEarthsea Master ZIP file and I’ve found the lines were I need yo change the code, but the problem I have right now is how to build the HEX file from those files. I think I need the LIBAVR32 installed but when I try to execute the “PREFIX=$HOME/avr32-tools make install-cross” command I get an error, as the ATMEL link seems to be down.

Any help with this? Am I doing something wrong?

Thanks in advance!!

i’m not sure the ZIP file will contain libavr32 as it’s included as a submodule. a better thing to do is to clone the repo with --recursive option - this will include the proper version of libavr32.

then you’ll need to install the toolchain - the atmel files link doesn’t work anymore, there is a couple of workarounds - check https://github.com/monome/libavr32 instructions (you can skip ragel and clang-format steps), if that doesn’t work, you could also try @dewb’s docker image (see https://github.com/monome/teletype for details).

Thanks @scanner_darkly! I’ve managed to do the compile but it has been pretty difficult to manage with the libavr32 extension. Finally I got it!

I’ve uploaded 2 versions of the firmware. In the first one each button is an increment of one semitone and also from the rightmost button of one row to the leftmost button of the upper one. It could be called a true chromatic grid without note repetitions (1 BUTTON 1 SEMITONE)
The other one has an increment of 12 semitones from each row position, so now all “y” buttons play the same note but on different octaves (1 ROW 1 OCTAVE).

multipass_ans - 1B1S.hex (185.3 KB)
multipass_ans - 1R1O.hex (185.3 KB)

1 Like

great, glad you got it working!

One more question @scanner_darkly … Is it possible to save presets in an external USB drive, like in the original firmware? I’m trying to do this by pressing KEY 2 but nothing happens …

no, it’s not supported right now unfortunately. i need to add it to multipass but this requires a significant effort, so not sure when i will be able to do it.

And one more question, @scanner_darkly

Is it possible to modulate the transpose option in the MOD BUS page? It seems to be possible to modulate octave and volume for the different voices but not transposition by pressing the button range …

Thanks!