#390

Kria scales would be perfect; thanks!

As for note priority in the case of mono:

I just thought that AEarthsea notes might stop “glitching” for some folks if the program can recognize when you have one key pressed and you subsequently press another key (while still holding the first key).

It seems as though (whatever the circumstances/playing styles), if two or more keys are held in mono mode, AEarthsea doesn’t decide which note should take priority and you may get nothing.

On a monophonic synth/keybed, you can depress multiple keys and only one note will sound (by virtue of mono), but because of the note priority settings you’ve chosen in a menu (last note, highest note, legato), the result is predictable to the user and consistent in the program (e.g. each key released in a group of held keys will ungate the next key according to chosen rules).

Maybe, I’m going too deep here; not sure…

#391

currently, this is how voice allocation works: when a new note is played it will check if there are any unused voices available. if all allocated voices are taken it will take over the earliest note.

it will always play the latest notes. if you have only a single voice allocated, and you press and hold a note, then press another note, the pitch will be changed to the 2nd note. but the gate will stay high since there was no release.

now, one thing to remember is that mono synth keyboards can retrigger envelopes if you overlay 2 notes, and ansible earthsea can’t (unless we use a hack with inserted gap). the reason for that is that such keyboards actually have access to both the trigger at the beginning of a note and the gate that is held high while a note is pressed.

it would be possible to replicate such behaviour if in addition to the gate output there was also a trigger output per voice, and you had an envelope that had a separate input for retriggering. then you would patch the gate into the envelope itself, and the trigger output would go into the retrigger input.

#392

Got it now…thanks for taking the time to explain the situation again. Not sure why the trigger/envelope concept didn’t click with me the first time, but it’s clear now.

It that case, I vote to leave the current gate programming exactly as is considering gate delays and/or additional outputs allocated to triggers would cause more issues (seen and unforeseen) imo.

#393

I’m probably in the minority, but at least for live performance, I’d like to experiment with option 1 if we can come up with a way to make it available. Option 3 is also workable, but the way I’ve been playing, gates would be nice to maintain.

this comes down to whether the voice selection buttons act as toggles or radio buttons - i was thinking the latter as it would make switching faster. could perhaps allow multiple buttons to be selected while held?

That sounds good. When one is held, pressing another would allow multiple selection, but pressing one remains radio button.

I’m not enamored with any particular multi-sequence implementation. Multiple mono sequences would certainly be lovely, as many have been saying. However it has to work is fine by me. Just looking forward to being able to layer. :black_heart: :sparkles:

1-Quantized, lit keyboard layout (as mentioned previously (I know my guitar fretboard, but it would be nice not to think about where I am on the grid constantly).

I’d also love to see the keyboard guide. I’ve gotten pretty good at finding my way spacially from practicing scales, but more visual reference points would be lovely.

#394

after more consideration i’m afraid option 1 is not possible after all… the main reason is that it would complicate several other features i’m considering adding. hopefully they’ll more than compensate!

1 Like
#395

Sorry to hear, but obviously you know the inner workings so I completely understand.

Any chance you could at least re-implement the code that @tehn added to the original Earthsea module which allowed you to light up individual keys of your choice and (I believe) save those lit keys with each pattern?

It’s been awhile since I’ve used an actual Earthsea module, so anyone who has feel free to iron out my ideas here…

Looking forward to the other features you have planned :grin:

#396

Just ordered my first Ansible and I’m already looking forward to installing Earthsea.

Any word on i2c ops?

1 Like
#397

so, we’re at the point where i’d rather spend time working on a new version. as i planned from the start the new version will be a complete rewrite, so adding features to the existing one doesn’t make sense i’m afraid.

with one exception: as the new version will take some time i will consider still adding things that are: 1) quick to implement and 2) are a common use case.

so, displaying scales and/or keyboard guide - might happen.
i2c ops - likely new version.

now might be a good time to mention the new version will likely have a somewhat different UI. again, i hope the benefits of new features will outweigh having to learn a new UI!

10 Likes
#398

If you’re totally rebuilding can I ask for opinions on brightness levels. Just wondering whether many people are having earthsea make the output of their case much noisier (high pitched) the more buttons are lit and the higher their brightness. I’m just worried an even brighter ui will make my problems worse. I haven’t seen much feedback on this though so maybe it’s rare, in which case ignore me. Thanks again for all the attention your giving earthsea, it’s my most used ansible mode.

#399

Awesome news about a new version. Looking forward to watching its development.

#400

Are you looking at significant changes to the UI? Any thoughts on how hard that might be to back port to the original Earthsea?

#401

I’ve solved this problem by externally powering grids.

1 Like
#402

i can lower the brightness of the progress bar in the current version, as discussed - it’s a super simple change. but need to consider non vb users as well, as anything lower than 8 in brightness won’t show up. but in general i’d say it would be impractical to make a new UI dimmer - it would limit the expressiveness of the UI without fully solving the noise issue. the noise issue really need to be fixed at the source.

mostly changes in the left column, rearranging some of the modes. re: porting - for any new dev my plan is to have a clear separation of hardware specific bits to make potential ports easier.

3 Likes
#403

I actually installed the tool chain, though I need to order the debugging cable. I had an idea for an Ansible app, so I was reading over the source code. Speaking at a high level, how are you considering changing your approach?

#404

couple of things:

  • separating code into 3 main components - hardware interface / UI controller / the engine
  • having clear separation in the engine between patterns and what is being played back (basically, having a separate data structure for what is being played with patterns being just sources for that data - should clear up some issues with hanging notes and allow for more non destructive runes and simultaneous pattern playback)
2 Likes
#405

i haven’t looked at the source for your ansible earthsea, but a while back, i started making some headway on making a basic template of an ansible grid all in its own .c/.h.

with the current structure of ansible’s grid apps, it’s a little bit of a kludge to add another. any chance you are planning on pulling earthsea into its own .c/.h in your re-write?

2 Likes
#406

yep, that’s my plan - leave the necessary wiring in ansible_grid.c but have the main implementation separate - agreed it’s a hassle having everything sharing the same file!

1 Like
#407

awesome. well, if it’s not too much work to leave some kind of blank template for a grid app in your process, it could go a long way towards opening up development of more ansible apps :wink:

4 Likes
#408

Wacky idea I’ve been considering implementing: a mode where you can record an Earthsea pattern into a Kria track (overwriting note, trig, glide, duration and loop length for the chosen track, probably not a precision-perfect record of your live play, but ready for chopping and loop-desyncing.)

I think templates for new apps and other strategies to promote safe and easy extensibility would be easier if we could adopt some C++, but it’s easy for me to say that because I’m already comfortable in it. What’s the general community feeling about C++?

1 Like
#409

Funny, I had a (not too dissimilar) idea where each ansible (grid) program could be mixed on the outputs rather than isolated. For example, an earthsea pattern on ch. 1, kria pattern on ch. 2, and meadow physics patterns/gate outputs on ch. 3 and 4.

Assignment of each output could be done within each program on a separate mixer page (like AEarthsea currently has). A dimly-lit key in the mixer page would denote a channel that has already been assigned/taken by another program to avoid overlap/confusion.

1 Like