#410

I am curious whether these Æarthsea innovations might also make their way to the Earthsea implementation on Norns (Nearthsea?) at some point.

#411

whoa!! (i haven’t been tracking this thread.) if someone could summarize the new features i could address updating the norns earthsea.

4 Likes
#412

EDIT: Was going to post some ideas I had for ES but I think instead I will wait to see what features the new version might offer.

Looking forward to it!

#413

yep, will do a template first!

it’d be nice to have some general sequence management in ansible, being able to store sequences from any app and then load them in any other app - this would require a deeper change though!

agreed c++ would be nice, but we’d have to port libavr32 first…

this would require multiple apps running at the same time - a much bigger change…

i’m behind on my norns studies so not sure how the norns version works, but i think the main request is to be able to switch between poly (where voice allocation is handled by earthsea) and mono (where you can dedicate a voice to a specific output pair, or for norns i guess that would be being able to assign voices to different synth engines?). i’m also planning to add the ability to play several patterns simultaneously.

3 Likes
#414

Swoon. If it would be able to preserve the timing and automatically determine the scale from the recorded Earthsea pattern, not only would that be amazing, but also impressive.

1 Like
#415

kria doesn’t allow variable step duration though (but not sure, don’t know it that well).

but what if we had a way to use kria and other sequencers where instead of notes it would use a sequence split into 16 chunks, kinda like mlr but using sequences instead of samples.

i think the most practical (and perhaps the most flexible) way to achieve this would be using teletype, and providing a way to obtain a sequence from earthsea (i’m definitely planning to add this by the way). so you could create a scene that would read a sequence from earthsea and store it in pattern data. and you can already read values from kria, so you could have kria sequencing that pattern data.

1 Like
#416

slight derail, but @markeats has lua lib functions for snapping sequences/notes to specific scales (along with a bunch of other functions), which is very exciting…

1 Like
#417

It does not. It has the wonderful ability to run each track and/or loop at different divisions of the clock - but I don’t think that’s quite enough to achieve the same thing.

Ah, this is pretty interesting. So, for example, I could read the Earthsea sequence into Teletype (note and timing data) and then do something with the note data (or timing, or both).

FWIW, I’ve found the ability to simply record the sequence that I’m playing a huge missing piece in my modular instrument. And, not being classically trained in music (and too impatient to learn) I also rarely understand what scale I’m playing in, or possibly even the time division from the master clock… both things I could figure out, but again… impatient. If something could extract that FOR me, that’s pretty awesome. Say, determine the scale from the notes I played. Or determine the tempo based on a combo of the length of the sequence and the closest approximation of timing between notes (even if it was a little sloppy). Of course I realize this could be less interesting to other (or a majority of) folks - so for now I’m happy to continue to improve on my abilities with the current AEarthsea.

2 Likes
#418

This sounds really interesting. Could you please elaborate on this idea?

#419

I was thinking (maybe too optimistically) that glide could be employed to create notes longer than a certain step, and per-step gate length on the last step could be adjusted to approximate the actual duration of the live-played note. Every note would have to be quantized to start at the beginning of a step, though.

#420

exactly!

so both are actually good examples of what you could do with a sequence transferred from earthsea to teletype - you could use it as a scale for a sequencer programmed in teletype, or you could have a script that calculates the tempo and outputs a clock. although both could just be done in teletype with grid ops, i suppose.

but still might be a neat thing to do, you could transfer a sequence and change the notes but preserve timing to create, say, a bass line (keeping in mind that timers are only 10ms accurate - need to think if it’s technically possible to improve it…) and apply transformations not supported by earthsea. or just use it to edit notes/timing and transfer it back.

imagine if we take an earthsea sequence and divide it into 16 equal chunks (by time). now imagine that you are able to play it mlr style, so you could easily have smaller loops created within the sequence. or using kria but where instead of notes you are sequencing these chunks.

10 Likes
#421

This sounds great. Can’t wait to try this duo with Marbles.

#422

I might just add this myself if it doesn’t make sense for the public app, but a way to add a rest/note-off during sequencing when externally clocked would be very useful. I’m about 30/70 on internal/external clocking usage, so that would be immensely useful for how I’ve been using it. Even more so once we have multiple sequences available.

#423

i can add that but i think the whole external clocking feature needs to be rethought. it should respect the original timing, the question is, how should we do that? i imagine you’d want to be able to specify if the clock represents a full bar or a specific number of beats (in which case we also need to be able to select how many beats per bar).

to replicate the existing behaviour there could be a separate quantization rune, and it could be implemented in a way that would insert rests if a gap is bigger than the average note length x2.

1 Like
#424

On one level, I kinda like the crude external clock implementation it has currently. IMO, the greatest thing about Earthsea is that it records exactly what you play when internally clocked. There are countless hardware sequencers that will quantize, either step based or realtime input, but I’m having a hard time thinking of one that is completely free time. If anything, I think it would be cool to extrapolate some kind of clock from what was recorded… but I’m digressing.

I’m guessing how the internal clocking implementation currently works is that a timer is counting the number of milliseconds between each button press during record, and on playback, plays a note, waits those ms, then does the next. If that’s the case, when clocked externally, could it count clock pulses instead of ms ? Sure you may have to use a high(er) clock rate to get a usable resolution, but that’s pretty easy in modulars now a-days with clock multipliers and dividers. Plus it would also allow for variable quantization… want 16th note resolution, feed it a 16th note clock, want 32nd notes, feed it 32nd note clock, etc.

2 Likes
#425

i feel the same way.

4 Likes
#426

This seems like a -people who are used to it how it works now will have a fondness for the existing implementation, and people who are new to it would like somethng that better reflects the original recording- situation.

For my ¢ ¢: How clocking works now is a pretty classic monophonic synth implemention. (I treat it like I treated the SH-101. Hence wanting some rests, they’re useful!) I’m fine with it and kind of like the contrast of purposes. There are some quirks to the current version that make it useful. Also fine with something different.

If there’s a way to preserve “classic” and add something more robust, I’d like that.

#427

a combination of quantization and the ability to specify how ext clock is interpreted will give you both.

say you have a sequence like this:

AAA______BB___

right now with external clock it will become:

||||
ABAB...

what i propose is adding the ability to apply (non destructive) quantization:

AAA______BB___

will turn into:

A_B

and the ability to stretch to external clock. full bar:

|             |
AAA______BB___AAA______BB___...

or, say, 7 beats:

| | | | | | | | | | | | | | |
AAA______BB___AAA______BB___...

combining this with quantization it will give you (for full bar):

|  |
A_BA_B...

which is the existing implementation but with rests added. i could do 2 different quantization runes, one with rests and one without.

does this cover your use cases?

3 Likes
#428

this is the case indeed. but in practice you’d want to be able to specify a pulses to ms ratio, otherwise you’d want to run a really fast clock (and it’d have to be divided anyway, to preserve original timing you’d need a clock that would run at 1KHz - it won’t be able to follow that since internal timing resolution is 1ms). it’s an interesting idea, especially if you can change the ratio, but in practice it would be just a way to stretch your sequence. and if you are trying to sync it to some external sequencer, you’d have to change the ratio each time you rerecord the sequence.

#429

I haven’t looked too deeply at the implementation of timing in euro earthsea (just enough for the VCV ports) but I’ve poked around at the norns earthsea script. This is what I had in mind for external clocking in norns ES: recording events not as ms-from-last-note-event, but as (N = clocks since last event, M = ms-from-last-clock divided by ms-per-clock division). On playback, events would be scheduled by waiting N clocks plus M * current ms-per-clock milliseconds. So events could be played at their original timing and speed, or sped up proportionally, or quantized after the fact.

How much overlap is there between ansible earthsea users and norns earthsea users? These ideas would be substantially easier to prototype in norns. It might be fun to make an ansible-grid script that combines es/mp/kr in the same way the module does. If only I didn’t have a dozen projects in the queue already…