#105

Only thing that comes to mind before making a release & committing to ‘scene-building stability’ for BEES is ‘pattern-selection’ inputs for whitewhale & kria. These will double as ‘sync’ inputs for those grid devices.

The only other aleph plan I have in the pipeline is a serial external for puredata - this may or may not even require changes to the BEES serial op but that won’t affect 99% of people’s scene building.

Now’s the time to look at the way I updated aleph midi if anyone’s planning to use midi. Mostly of interest to me so I can use aleph as sync master with my looper & use an fb1010 foot controller but I aimed to finish the midi implementation enough for any reasonable usage which doesn’t require simultaneous grid connection…

EDIT:
As an aside, I might attempt a ‘patching study’ using the aleph front-panel controls & screen op as a melodic or rhythmic step-sequencer. Could combine almost any of the aleph modules with a piece of midi gear to pretty unique effect I think!

1 Like
#106

only other thing is wanted to fix the cv output issue (see open PR for details) . Rick had a hardware issue that blocked his progress, and I just haven’t had any time… guess we could save that for 0.8.1 since it wouldn’t affect bees side

1 Like
#107

yea there are also a couple of outstanding issues with grains module that will get attention in the coming weeks, but this needn’t block the 0.8.0 release. I can give the ‘sync’ inputs for grid ops a quick hack in puredata/linux BEES pretty much right now.

A computer connection to linux/pd for performance gestures will be the icing on the cake as far as I’m concerned but, again, it can wait. Gives us a manageable but still very significant feature list for 0.8.1

2 Likes
#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?