#110

i’m sorry i just haven’t done any work on new operators. they are not difficult but i’ve been working round the clock on other things, for weeks. i hope i can find a minute soon

#111

Ah fine idea, although it’ll always be tricky in live situations. The hub problem somehow pushes for simplicity, but I do often get annoyed having to make a choice (grid or MIDI, typically). Still, sounds very exciting and I am very much into FM at the moment (with a Kurzweil PC3K6 and a Yamaha TX-802, mainly) so I’ll be happy to try it out, maybe propose something even!
Anyway, do you think we should aim for drawn examples, add explanations, only put some patches? I mean, the point is for people to learn and share but there are many ways to do this…

1 Like
#112

Well, good luck with finding time indeed! I have been thinking a lot about LINLIN (quite a handy operator savior), CHAOS and stuff like GRIDSCROLL quite a while (I actually made use of a MEM1D with up to 128 X values for a scene already, in order to store extra elements for a sequencer but that was unknowingly exploiting a bug in the MEM1D operator, corrected since then). And am looking forward to the day they will appear.

By the way instead of FLIP I have been using mostly presets, which got me exactly to what you are describing quite easily (often using an ADD so that one of the two presets isn’t always 0), but mostly a HIST2 object I derived from HIST8: each TOG (0/1) brings a switch on both sides (and we can remove the mean calculation from it, so that it only features one input and two outputs). We could incorporate that one maybe, if you don’t have time for the full FLIP?

#113

also been revisiting lines with fresh ears the much-improved patching system & a casio SK1. Even the performance possibilities of a dual-tap-tempo pingpong delay are somewhat interesting and not something I’d tried before.

There’s one point that always frustrated me about lines’ params for looper - it’s the fact that time units on the loop & delay params are not milliseconds, they’re 64/48 ms (iirc)

I’m going to look into it again very quickly. Have a strange feeling it’s actually no big deal to use the fract primitives to do a unit conversion there.

1 Like
#114

I didn’t know that about the time units. Interesting. I also like the ability to overdub with amplitude differences.

I think it would be a short sweet project to get a tap tempo or global BPM clock dual looper patch going.

#115

Felt a pretty urgent need there for a LINLIN while I was patching the casiochop study & having integer-multiply overflow issues - this is a vital feature https://github.com/boqs/aleph/commit/e1defac095f8055c87d30390e1297199ac90c8c1 . There’s also a ‘dividing clock’ operator on my branch - so you can send the output of a TIMER to CKDIV/PERIOD - then set the number of ‘tocks’ to send between every ‘tick’ - that was an essential tool for this evening’s patch.

4 Likes
#116

I want to put the issue of how to index time on aleph to bed once & for all, like today if possible! I realise @zebra must be too slammed with work to think about this but my own work situation will be the same again soon enough - so it’s got to be now!

There are two viable options as far as I can see:

  1. times are always expressed as an integer number of 1 millisecond ‘ticks’ in both BEES & lines
  • pro: milliseconds are a good unit to be thinking in
  • pro: it’s what we already have in BEES
  • con: longest time we can measure/express is 32.769 seconds, which might be a little brief for some.
  1. times are always expressed as an integer number of 2 millisecond ‘ticks’ in both BEES & lines
  • pro: longest time we can measure/express is 65.534 seconds, in line with people’s existing lines usage
  • con: extra mental burden of always having to mentally divide/multiply by two when setting timings manually
    (- con: is there a case that says 2ms is significant for timing jitter? I really don’t think so)

No strong preference for option 1/2 - they’re both unsatisfying compromises. It’s almost zero work to switch on the code side but my feature branch is currently at option 2. Help me make up my mind which is better!

Both open up lines for the seamless synchronised looping/chopping workflow I always knew the aleph was capable of. I believe that unfortunately the param descriptor for lines needs to be changed whatever happens, breaking scene compatibility.

Sorry for the scene-compat @dspk, @glia, any others with existing library of lines patches. (I could easily be convinced to fork lines again if there are cool 0.7.1 patches which would otherwise work with 0.8.0 - ‘synchrolines’ would be the chopping-looper-optimised version of ‘classic’)

#117

I’m fond of thinking in milliseconds. For me a 60 second buffer isn’t a compelling feature to have to do division. I mean, those Line6 M series looper pedals have 28 seconds of buffer and they are quite popular.

#118

i’m away from my aleph not very good at this kind of abstraction (therefore have no idea how this will change things without some kind of example…)

how is this different from what we have now?

#119
  • with option 1/2 lines’ loop, read_pos and other ‘time’ params will look visually identical to metro params
  • for example 1 second duration will appear in the menu as 1000 (or 500 with option 2)
  • if you measure a tap-tempo duration using BEES’ TIMER, you will be able to pass that number directly to any lines input
  • with option 2, the max. length of a ‘line’ will stay roughly the same as now (around 60s)
  • with option 1, the max. length of a ‘line’ would reduce to 30 seconds
  • (trying one more time to find a third option where I don’t have to change lines’ param descriptor)
#120

if we’re gonna change the lines params, why not add a scaling parameter in the module?

#121

Both are fine to me, to be honest, so I guess it’s all about what you can hear or not. If it makes a significant difference in terms of sound I’ll always go for quality instead of quantity. Then again if there is no audible difference, why not use 65 seconds indeed? By the way, could you implement something like that in the Grains buffer as well?

Ah also, I don’t think we should aim at keeping the scene compatibility systematically, as it will make Bees heavier and heavier (having two versions of the Grid objects, for instance): version 0.8 will be a big step forward, and we should all take advantage of its potential by developing new stuff and eventually porting the old on it, which shouldn’t be too difficult.

3 Likes
#122

Like, a single extra integer param which acts as a global multiplier for all of lines’ ‘time params’, enabling integer multiple of 32.8 seconds total length? Sounds workable to me!

1 Like
#123

yeah exacerly. like on i dunno, a boss dd-20 you can set “meter” which just multiplies the tap.

does it even need to be an integer?

#124

cunning! mul/div representation or 3.12 fract representation?

#125

I know these are scene breaking due to param name switch but I dont really have a problem with the switch (my scenes were broken anyway)

Open to anything but prefer the idea of long buffers.

#126

i would lean towards fract. whatever radix would max out SDRAM usage for the buffer sizes. that’s exciting, we haven’t really tried it before…

1 Like
#127

buffer load/save to sdcard feature for 0.8.1 then? (what am I saying, this is crazy talk!) I think it should be done as a BEES page with a list of 32-bit .raw files - just duplicate the modules page for UI, but dump as much of module audio SDRAM as can be transferred in, like 20 seconds, to/fro sdcard. Isn’t this actually a pretty straightforward little hack?

Putting that thought on hold for now, I calculate the right radix for time-scaling param is 2.13. With this new scheme, max loop length for each line (at 4ms worst resolution) would be just over 2 minutes. Much more of a win-win!

2 Likes
#128

i know @Test2 got something working with streaming audio files from sdcard, for prgrm. i lost the link to the thread about it…

i do remember it was slow. and then i saw this awful thing:
[ https://github.com/monome/aleph/blob/dev/avr32/src/interrupts.c#L75 ]
(a very long delay in the PDCA interrupt. i really hope that’s not actually necessary. no wonder it takes so long to save/load scenes)

really making me want to strip down preset/scene size to fit at least one in nvram.

#129

really good conversation on this! really glad to finally have this sorted (believe it’s sorted now - just added the time-scale param to lines).

since we’ve agreed to break scene-compat for lines I feel like we could very easily free up quite a few cycles in lines by making the filters either low-pass, high-pass, bandpass or notch & using the ‘label’ param-type so it displays onscreen as a filter-name, not a number. The code can be copy-pasted from acid’s monosynth voice so this is an easy enough change. Would everyone agree with this decision? Or are people using the existing feature for no-input-mixing techniques fading gradually between filter types?

I thought this could free up enough bfin cpu time in lines to do, for example, linear-interpolated reads on one/both channels. Or make write heads fade in more cleanly on recording start. We should be able make these improvements in 0.8.1 without breaking 0.8.0 scenes if we change filter params now…

scrub the suggestion on modifications to lines’ filterbank… lost perspective there on the overall direction, sorry for the line noise…

I didn’t mean to get sucked into a major overhaul of ‘lines classic’ - the original design is fine apart from that stupid timebase incompatibility thing. It can definitely do the ‘beatslicing loop pedal’ thing now (along with the multitiude of other things it already did/does)

2 Likes