ah hellllllll yea niklas this is super good - super cool to hear you gellin’ with it
new version - fixed some issues with the buffer switcher switcher which was notttt working well ---- should b better now if not all the way fixed
I’m finding that I need to hold two and release one, at which point it glides fast towards the one released last. Is that correct?
I’m also finding the loop lengths seem longer than the time I held the leftmost button down.
At any rate it’s great fun so far!
this looks wonderful
it shooould glide toward the second key pressed, there might be some edge case bugs though.
by how much ? If it’s ~ 100ms or so I may not me noticing the issue, If it’s more It may be in the realm of a performance isssue (this app eats up yr dang cpu)
I’ll try to check more this evening…
Thanks!
also put a new version up last night with location keys && a fade parameter. might’ve fixed some bugs too I forget
this is twenty characters of dopeeee. Is there any way to route the buffers through send/returns?
Upon testing this out it seems that there is a delay in the incoming audio from the press of the record button at the beginning of the loop. I turned fade down to 0 but still notice a decent amount of delay in signal. This test was done by routing audio from another Ableton instrument into anachronism though. I’m not sure if that would have any affect on the outcome.
like ableton return tracks ?
currently: you can put metonymy a separate track, send up to four lines to metonymy
soon: you can make 8 tracks with an instance of ekphras.satellite in each track, use the sends on the track
ekphras.satellite
meh yea this is latency - the way I handled the diction thing to send data between the devices is kind of dumb. I need to work on a way that’s more efficient. I’ll work on testing what the latency is like on my machine. It’ll vary between computers probably.
diction
This is what I was experiencing as well…
@Prnts @eblomquist are you able to share an audio example of the record latency thing (and re-download to the latest version first) ? I’m testing fine but I also may not be quite as sensitive to it if it’s something small.
NB that softcut parameter changes are not sample accurate but are enacted on audio buffer boundaries. So maybe check buffer size and experiment with making it as small as possible
ahh, this could be related - buffer size is 8 minutes by design but I could make that more dynamic.
but there’s also a real possibility my data streaming between grid <-> softcut is causing delays, I’m basically updating and reading from a big-ish JSON string (between js objects)
js
Im talking about the audio processing buffer size… not the record buffer. maybe not relevant but something to keep in mind. The thing was made for norns where it is assumed the buffer is small and control jitter correspondingly low. In ableton it’s common to have much larger buffers to accommodate lots of disk streaming &c
riiiiight this makes more sense. so this bit:
my shoddy javascripting seems like a more likely candidate but worth messing with
512 is noticeable latency (I can’t record anything live from a mic at 512) I don’t know where your issue lies here but 512 is quite high buffer size. (I mostly work at 128, 256 if the session is heavy)
yeaaa but I’m the one not having latency issues
Ahah, I’m off you C++ nerds! Go javascript the world away!
Will try to do something tomorrow. Would an Ableton set be helpful?
