#108

That sounds just fine, looking so much forward! @rick_monster I can test the MIDI if it helps, no big deal. And by the way @zebra, how are the new operators going? By the way I think we should start incorporating some simple patching examples for some of the operators, maybe directly linked to the documentation when v0.8 is released. I can do a few, and it can evolve with time I guess… what do you say?

1 Like
#109

Some midi testing would be appreciated - hope there are no bugs! ( I did test pretty thoroughly though)

As for patching examples, yes couldn’t agree more - the study group thread is well overdue for some… studies! I’d like to repatch (there was an earlier version) & post an fmsynth/preset study really exploring how to build a really fast, powerful FM-tweaking iterface using grid, arpeggiator-patch & aleph front-panel (then unplug the grid & have a bunch of cool recall-able FM presets to drive over midi). Obviously the same approach/use-case applies to dsyn & acid…

1 Like
#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