#101

I just tried it - it is just called ARC, right? Here I mostly see these differences:

  • Everything is limited to 64 values (0-63) now, which is somehow a shame I suppose.
  • No Loop function (which decouples the 64 leds and the 256 internal values).

Then when I tried it, for instance creating an LFO on Ring0, which speed is given by turning Ring0 itself, here are the issues I get:

  • I need to erase each led before lighting up the next one (if I don’t want the ring to get entirely lit at once), and can’t use an ITER object for that as they are limited to 16 iterations so far. That would be quite a lot of work for not much anyway, but the gymnastic requires quite a lot for each ring and that is annoying so here’s what I would suggest: an extra input that allows or not to have only one lit led at a time, either one for all or one per ring.
  • Then it seems the Aleph has a hard time dealing with refreshment on the ARC, so that below a METRO/PER of 40 or so, things become blurry and then visually wrong (the led jump up to 8 slots when reaching METRO/PER = 5). Is there a way to make that better? @tehn?
  • Finally, I made it work for one encoder anyway but things got more complex when I added a second one with the same principle: the Aleph can’t seem to cope with the timing on both sides, so that one ring influences the other. I think it has to do with the fact that for each iteration on each side I have to remind the Aleph which ring to send to. Somehow it seems too much for it, unless there is a better way which I didn’t (here I mostly decoupled everything in order to avoid confusion).

Here is the scene I created for that occasion, if somebody (@glia ?) wants to test and eventually improve it : Test_ARC.scn (256.1 KB)

Basically, Ring0 and Ring1 modify the speed of the two LFOs that make them move forward respectively. Switch 1 and Switch 2 will perform an on/off on each METRO driving the LFOs, so you notice the difference when both are running together: NOT the same thing!

Edit: just to add that I just tried the same patch with the previous version of ARC, and setting LOOP to 0 gave me the same result. When set to 1, I could see the value of the encoder as a second led for each ring (until it got erased by the LFO), but that’s it… At this stage, as it takes quite some programming space and can’t be chained with a Grid, unless there is a module taking specific advantage of it, the ARC is pretty much useless with an Aleph in my opinion. Anyone else?

#102

yeah, I was thinking along these lines - the ‘patch programming’ of GRIDRAW definitely enables some useful things - especially ‘painting’ visual cues on a button-grid. But for ARC, is there really a usage for ‘ARCRAW’? (i.e a raw interface to simply paint the LEDs & receive raw deltas).

sounds like possibly a bug in operator code - obviously I can’t test anything…

Well, I think the best way to use arc with aleph is to design specific ops for specific tasks. So I think ‘useless’ is a little pessimistic - I’d say ‘blank slate’! @scanner_darkly’s original orca tutorial is quite inspiring!


but yeah, obviously we already have a lot going on with aleph - we need to really finish nailing down the control-voltage output bug(s) so I shouldn’t get sucked into thinking about arc…

#103

Agreed, it was way too pessimistic. I meant mostly that there is a lot of work to do still there, so that it is probably not worth spending time on it, at least before the next release.

2 Likes
#104

So how are things, fellas? I am about to develop new stuff, but am a bit afraid to lose backwards scene compatibility so I just wanted to know if we were in any way close to the release… @rick_monster? @zebra? Also, anything I can do to help at this stage?

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