#99

So on the subject of BEES’ preset system… Currently (as I understand it) the list of which inputs/outputs (set via INC/EXT) is ‘global’ across all presets.

Wouldn’t the aleph preset system be significantly more useful if the list of INC/EXC params were actually stored inside the preset? So for example you could set up a scene where:

  • presets 8-11 recall particular subset of the DSP parameters (e.g a single dsyn voice)
  • recalling presets 0-3 affects just the encoders
  • recalling presets 4-7 affects just the switches

This seems like a great idea to me, and hopefully manageable without cluttering the UI - wondering what other BEES users, devs & other aleph enthusiasts might think of this (obviously scene-breaking) change?

EDIT:
reading through the source code it looks like this is already what is supposed to happen, interesting…

EDIT:
just fixed a couple of pretty trivial bugs affecting preset system (leading to this misunderstanding of the design) - will post a minor update with these changes after testing some more…

1 Like
#100

I like how the presets work in buchla system. They are global, but you can opt-out any individual module with a remote switch. Also the ability to sequence the presets was great.

#101

( if i understand the question correctly ) I think this is already the case…

have a look at this scene and docs i posted

https://llllllll.co/t/aleph-scenes/3543/46?u=dspk

https://llllllll.co/t/aleph-scenes/3543/55?u=dspk

(BTW loving your bees update!!!.. about to rebuild this scene to work with it… though i do miss the lofi quality of the old pitch shifting a little bit)

#102

yes, that seems to be the case, but pretty sure there’s a bug… If you include an input/output in a preset, then subsequently exclude it, & re-write the preset, that input/output doesn’t get deactivated.

That’s why I got confused about the original design intent.

also another bug where presets get mangled by arbitrary op deletion

fixes for both problems seem ok so far!

think old lines will work just fine with updated BEES - might be a good idea to make a new module for the varispeed version, preserving ‘lines classic’ to avoid confusion & maybe even allow loading your old scenes rather than having to rebuild everything. Scene backward-compatibility should only be broken for certain grid ops & I don’t remember seeing a monome in any of your videos…

1 Like
#103

Ah you might be right there. Would explain some weirdness that I’d always attributed to op deletion.[quote=“skektek, post:102, topic:177”]
also another bug where presets get mangled by arbitrary op deletion

fixes for both problems seem ok so far!
[/quote]
Oh boy yes… I very often have to reassign half of my preset destinations if I delete any opp (even on I have just added and haven’t used!) [quote=“skektek, post:102, topic:177”]
think old lines will work just fine with updated BEES - might be a good idea to make a new module for the varispeed version, preserving ‘lines classic’ to avoid confusion
[/quote]

In terms of making a new lines module can I just copy old one, rename it and throw in the folder? Or do I have to do some makefile stuff[quote=“skektek, post:102, topic:177”]
Scene backward-compatibility should only be broken for certain grid ops & I don’t remember seeing a monome in any of your videos…
[/quote]

I have. Gs64 tucked away but haven’t used it in a while…(just for Parc on my laptop mainly. Prob my favourite sequencer ever) Your new opps are tempting me to dig it out!

#104

think that would work! Let me know if not…

EDIT:

Another ‘non-release’ of aleph firmware - this fixes two bugs in the preset system. Here’s the patched code & an updated sdcard image (only aleph-bees.hex has changed)

http://nshgrtha.net/sdcard_sktk1a.zip

http://nshgrtha.net/aleph_sktk1a.tar.gz

2 Likes
Aleph release zip 0.7.1 cannot load scenes
Hi, I have an Aleph
#105

That looks fantastic, will try it as soon as possible!

#106

just to let you know that my old scenes (from Bees 0.7) seem to be working fine in your new version (and i can delete ops without screwing everything up!! ) and it was also possible to load both versions of lines (haven’t fully roadtested that yet)
yay!

1 Like
#107

given the number of existing scenes for ‘classic’ lines, (and the incompatible parameters) I think it’s best for a ‘stable’ release that the two versions should both be available in the source code under two different module names - e.g lines (for backward scene compatibility) & varilines would be the new varispeed version.

2 Likes
#108

@skektek hi… wondering if you could give us a bit of help/info on how the MEM operators are supposed to work ? i’m assuming i should be able to store values in them but maybe that’s not the intention as I can’t seem to get that to happen? thanks!

#109

So @dspk the mem operators absolutely are designed to store values. To use a MEM0D:

ENC1/VAL -> MEM0D/WRITE
SW1/VAL -> THRESH/IN
TRESH/HI -> MEM0D/READ

Then should be able to display the visibility of output MEM0D/VAL on play screen. this patch will store the last value output by encoder1 in MEM0D, and recall it when you bang MEM0D/READ with a button press.

Another use for MEM0D is to always output a particular number (call it n) whenever any number bangs read. Prior to MEM0D the only way I knew how to do this was MUL(0) -> ADD(n).

Here’s a recipe using MEM1D:

  • set the range of ENC2 from 0->16 in increments of 1
  • ensure MEM1D/TOG is 0
    ENC2/VAL -> MEM1D/N
    ENC1/VAL -> MEM1D/WRITE
    SW1/VAL -> THRESH/IN
    TRESH/HI -> MEM1D/READ
  • enable play-screen visibility of output MEM1D/VAL & input MEM1D/N to test this patch.
  • ENC2 selects the memory index
  • twisting ENC1 will write a value to the currently indexed memory location
  • pressing SW1 will recall the last value written with ENC1 to the slot indexed by ENC2.

MEM2D is identical to MEM1D, except it’s memory is a 2D array, indexed by the inputs X & Y. You’ll see that the operator GRIDRAW outputs in the following order:
X, Y, BUT
so the functionality of MEM operators is pragmatically designed to play well with GRIDRAW. For example store the Y value of grid button presses in a MEM1D, indexed by the X value:
GRIDRAW/X -> MEM1D/N
GRIDRAW/Y -> MEM0D/WRITE
SW/VAL -> THRESH/IN
THRESH/HI -> MEM0D/READ
MEM0D/READ -> MEM1D/WRITE

Please let me know if any problem or bug when setting up the patches described above. Hope you find this dark magic useful & powerful once mastered!

3 Likes
#110

ok great. i was struggling with the recall. sorted now… but what’s the significance of the TOG ?

#111

Haven’t had a moment to load this into my Aleph - but I just wanted to say how much I appreciate all the hard work that went into this. There is so much potential in that little box; it is nice to see more of it unlocked!!

Thank you!

1 Like
#112

it toggles the indexed memory element on/off when banged with a number greater than 0. Similar to WRITE, it doesn’t trigger an output. Again a pragmatic design so that you can achieve a toggling memory like the toggle mode of GRID using a GRIDRAW & a MEM2D.

All the building blocks are now there for a module which emulates in some sense a patchable virtual modular. Some module examples could be, e.g VCA, filter, env, pitch detection, mixer, varispeed tape loop. I’d hope to set it so the user can actually customise which & how many ‘submodules’ are in their blackfin module by modifying the header & recompiling (check the sourcecode for acid, you’ll see a proof of principle) The patching would be controlled via labelled patchpoints like the grains module.

also something combining part of the ‘acid’ DSP with one ‘line’ would be cool, so you could do some kria/WW sequencing sync-ed to a hack-able looper without carting multiple electronic gadgets around. That’s an interesting concept to me - the line could be used for resampling/mangling bfin-generated sounds as well as a looper for external instrument. Needs some thought/planning & a clear shot at the coding.

3 Likes
#113

cool to see a different approach to patching, I’m totally in on the module “patchability” idea.

on a side note I recently got hung up on a possibly silly idea to use the bfin for graphics/video. notably I have yet to find out if this is something worth pursuing considering that it would “divert” from the original idea/design etc, but I would be up to discuss possibilities.

3 Likes
#114

[quote=“skektek, post:97, topic:177”]
With no grid, this should work:

  • first set SIZE to 6
  • then set 2 encoder ranges both 0-6
  • connect those to X & Y
  • connect sw1 to BONK
  • hook up Hz to a Hz input on, e.g waves.
  • set play screen visibility on X & Y to see where you are on the square
  • tap SW1 to emit a Hz value

with a grid, create a GRIDRAW & a HARRY:
X -> X
Y -> Y
BUT -> BONK
[/quote]Searching here on the forum aint bad but I’d like a hub for referencing all updated features/ops/etc

It would be awesome if the docs were refined to include updated “studies” (and more generally reflect the staggering progress in development since the last update)

#115

btw…@skektek thank you for the incredible work recently

not sure if the ops for grid patching were inspired by @rick_monster @Yann_Coppier ideas from last yr

1 Like
#116

Hello hello… Just saying, but I have been using Grains a lot more in the past months. I can honestly say I have enough good material to make a record now, and a lot of it comes from that sweet module! An incredible lot can be done, and I have made some scenes to make things easier to control. Will be back shortly to explain what I did and share. In the meantime, I’ll have to ckeck all the new stuff that has come for the Aleph recently, which seems rather crazy! By the way I was wondering if, for instance, the MEM0D and such (from @stektek) were the same as yours, of some new versions?

3 Likes
#117

Diving back into this update again tonight and will post a scene. Really been pleasantly surprised by the drum sounds aleph is capable of by tweaking the acid app. Scary good and definitely grittier than most would expect from pure dsp.

Finally put down acid long enough to test my old scenes this week and none are working :frowning:

Don’t really mind rebuilding em but…is anybody else having the same issue?

#118

@skektek @tehn its long overdue but i think we should just roll these changes into the upstream.

the main thing the aleph needs is still a better UI / patching language for constructing scenes offline / over socket. it should not be hard, we just need to get it done…

1 Like
Aleph wobbliness (and emulation)