i see, so you mean just being able to adjust speed relative to external clock? doable, but i’m afraid this will go to “implement later if at all” pile… the main reason being - this can be done with an external clock div/mult module, and need to draw a line somewhere so i can get back to teletype firmware (this was supposed to be a quick port!).

for editing do you mean adjusting notes or timing? step sequencing wouldn’t allow you to change variable timing (which is why i was imagining it as some scrollable UI which would present both the pitch and the timing info).

2 Likes

I was referring to adjusting individual notes for variable timing… so looks like its not possible :sunny: thanks for your inputs though, still super excited to see this happening!

1 Like

yeah, i can’t think of a way to do this without creating a dedicated UI.

however: i do plan on adding teletype support which will allow you to read and edit individual notes (basically, an op to get the total sequence length and an op to get or set individual note properties. kinda like treating aearthsea sequence as a pattern bank).

1 Like

how about empty note or rest when external clk is present? meaning to create an empty event / trigger somehow?

you would need to be able to enter them somehow (which goes back to the above discussion on step sequencing) or analyze the note sequence and decide on when to have a rest based on some criteria. you could do something like this:

say, you record note A for 2 second, 2 second pause, note B for 3 seconds, 1 second pause, note C for 6 seconds, 2 second pause:

AA__BBB_CCCCCC__

now you clock it externally. we could infer some timing information from the first note. so any pause that is equal or longer than note A will become a rest:

A_BC_

this could be one way, but i’m not sure it will work well for all scenarios.

edit: thinking about it more, it might actually work reasonably well this way. so then the length of the first note would be used to determine ties/rests. linearization would work similar way (or maybe have the new option in addition to how it works right now). i’ll give it a try.

1 Like

Starting to make some headway on the docs.

Here’s an early draft of what I hope will turn into a printable (or PDF-able) quick reference card. I’ll probably slice this up as well for the markdown docs. Early days.

All comments welcome.

(note that I don’t use Adobe Illustrator, so I quickly copied @laborcamp 's excellent original images and did a bit of quick cutting and pasting to match. can be done better later, once I have all the bits is place and correct)

21 Likes

more than happy to help with prose for Ansible documentation - the grid modes are a bit less fullsomely described than the Arc modes in general.

3 Likes

thank you, that looks great!!

and reminds me, i was going to ask, the 3 bottom control buttons (for selecting gate mode / runes / voice allocation) right now work as momentary buttons, their pages are shown only while the corresponding button is pressed. so to select a different option or to execute a rune you have to press a control button, hold it, then press something else. this means it has to be a 2 hand operation sometimes. this also makes it less playable for when you want to perform multiple actions on the same page (say, if you want to change direction back and forth with the reverse rune).

to address that i could change them to one of the following options:

  • make them latching buttons, so you don’t have to hold. the downside here is that it requires another push to go back to the main page
  • a variation of latching - you press and don’t need to hold, but once you make a selection or use a rune it goes back to the main page (this option is also not very usable for multiple presses)
  • maybe latching could be a button combo. so it works as before but if you press a control button and then start/stop it will latch and the page stays on.

thoughts?

I personally like them being momentary :slight_smile: but the hybrid option sounds interesting, as does the button combo to enable latching. I don’t think a latching button as the default would flow as well. imo

1 Like

I also prefer them to be momentary, but the third option of being able to latch them on command sounds great. We could use the right next button of each control button instead of the Play/stop.

Also, I’m not sure to understand the behaviour of the “Half/double speed” when an external clock is plugged in. It seems to not affect anything if you click only one time, but if you click ex. 3 times (or more) on “double”, it messed up the sequence (like skipping notes).

Edit: if it not supposed to act like that, maybe the rune could disappear when an external clock is plugged in.

Using the Half and Double speed runes while externally clocked produces some strange results for me. I just assumed they wouldn’t work, and that’s kind of true I guess. Increasing speed by 1 press causes the cv sequence to speed up, but the gates stop firing and the grid no longer displays the notes being played. Increasing speed by 2 or more presses adds dropping notes to the mix. It seems to go back to normal if I slow it down to the original speed.

Slowing down past the incoming clock doesn’t seem to do anything.

1 Like

unrelated to the rest of the discussion but i thought id share. i demonstrated to my 4 year old daughter how to record and playback patterns on earthsea yesterday. she got it in only one try and then spent the next hour making music.

36 Likes

It could have a similar latching mechanism as the original Earthsea has for portamento?
Tap-to-latch, long press for momentary

Otherwise I would vote for option 2.) Variation of latching

1 Like

it could be a variation of portamento where if you press and release it it will latch onto that page, but if you press and then change an option or apply a rune it’ll go back to the main page once you release the button. i do like the fact that latching is more explicit with option 3, as sometimes you press a control button but then change your mind - with the portamento button approach it’ll latch which isn’t what you want in this case.

i also like the idea of latching with a button directly above instead of start/stop.

re: doubling speed messing up sequences when clocked externally - this is due to the fact that at some point notes become shorter than the chord threshold, so it treats bigger and bigger chunks of a sequence as one big chord. this will be fixed once i make speed runes non destructive.

@David_Rothbaum - thank you for sharing that! just so seriously awesome. i’m struggling to put it into words without sounding like a cliche, but seeing that is really the best reward.

11 Likes

well, thank you for all your work! i think it is a testament to the work that goes into this whole ecosystem that allows these devices to be both complex and challenging but also super intuitive and fun. its awesome to be able to share this with my kid (she loves teletype as well). i want her to feel confident and comfortable with both technology and music as early as possible and this is a great way to do that. so cool to have her drag me into the studio wanting to use the synth to make “her music”.

5 Likes

Possible bug:

If you record a pattern while the Reverse rune is active, the sequence will play back Forward and transposed down. At this point, changing the direction back to forward causes the sequence to play in reverse.

Edit: If I think of it more like tape the recording direction thing makes sense, but the pitching down?

thought i fixed that… the current reverse implementation is not perfect. when i get a chance to continue working on aearthsea this will be definitely fixed.

“more like tape” - ha, now i’m thinking it’d be cool to have speed runes also change the pitch… (joking, but as separate runes maybe)

3 Likes

With 20 characters worth of slew on that pitch shift! Lol

1 Like

Out of curiosity, I’ve seen mention of not supporting portamento. Is this a practical consideration or a hardware problem?

not a hardware problem - it’s more due to me trying to keep the scope smaller and also not being sure how it would work in a polyphonic context. would it apply to all voices equally? if not, how do you set it per voice?