Visualization tutorial on the Aleph

[glia]

at some point you have to do a video on setting up those 16 presets! (…or i’ll recheck the text tutorials)

anyway i havent added cv tweaking yet but i made a simple toggle with one of the switches

surprisingly, after clearing the printed numbers on the initial press, any subsequent toggling freezes the screen and “saves” the image with no overwrites

after testing i might map this to one FS for perfectly timed, hands-free pausing

here is an example of such a frozen aleph bar

also i’ve nicknamed the scene, and all its derivations, loom

[Yann_Coppier]

Ha great - and loom it is, then!
I am working on a more advanced version, and will tell about it later on.

[Yann_Coppier]

Yes you stopped the SCREEN function, so it freezes at least until you send a PRESET, a BIGNUM or whatever else I guess. Then it’ll disappear and won’t come back until you enable it again. I did the same by stopping the METRO, but it freezes the sound at the same time - unlike your case I presume.

Then this is the preset system I was talking about, directly inspired by the way the 4 lower bars of the STEP objects are working on the grid. Basically it’s a binary-to-decimal system, no switch sends preset 0 and all switches send preset 15. Now if ever you get problems in there - for instance you want to get to preset 3 by pressing SW1 + SW2, but it first launches preset 1 and then 2 because you didn’t press them simultaneously (which depending on your scene can be a problem or not) - there are a workaround or two: for instance you can add a footswitch with a value of 16, toggle=0. This could send PRESET 16, which will momentarily remove the connection between this diagram and the PRESET/read object on the bottom. PRESET 0 restores that connection. So you’ll press the pedal, make any combination, hold it and lift the pedal - then only the preset is sent. Just need to get used to it, which should come fast, but this way you won’t have any problem during a performance. Oh and you can as well use the step object and use the 4 lower bars of your grid to step sequence your 16 presets

I do love presets on the Aleph, to me they are by far the coolest feature and allow things I couldn’t possibly do otherwise.

Anyway I’ll make a basic Loom scene very soon then, for other people to enjoy and start some development. @glia, you are welcome to bring some ideas in!

[laborcamp]

Loom is a great name for this!
What an awesome, fun project.
I love when things are used not for what they were intended for (and I mean this in the best possible way), even though, I can easily imagine a kind of visualization that actually reveals certain aspects of the composition that might otherwise go unnoticed. Or visualizations that in the live preformance inspire new directions or structural ideas…
In any case: I wonder what craziness might be possible on the Teletype!?.. it’s probably a similar OLED screen between the two.

[bkinsman]

this is soon cool!!!
any chance of a written tute?

[Yann_Coppier]

Can be done, sure, if it makes sense. Then again, @tehn, does it? I mean, I’ll do it gladly but only if it brings something to what already exists, otherwise I suppose making a proper scene will be more useful.

[glia]

I’m revisiting this thread because i need an app for a new project with the power to draw an envelope and have the audio affected by it in realtime

might be wiser to build from scratch but i figured loom could be hacked to do something similar

has anybody already tried this?

[Yann_Coppier]

Well maybe, but could you be more specific about what you are looking for? I have some time this week in between two mastering sessions, so it could be fun to work on some Aleph patches indeed.

Anyway I suppose you want to do this with Lines or Grains, right?

[glia]

Yes exactly @Yann_Coppier

just after posting I remembered this was built on Waves so the first step would be rebuilding loom screen functions into Lines so that ext input would be easily used

My idea is simple: link the amplitude of the mixer channels to the xy coordinates being displayed (or the brightness…but that may make for a more abstract representation). Encoders would be used to draw an envelope and the mixer would shape the incoming sounds accordingly

[Yann_Coppier]

Well on the principle it sounds rather easy but shaping the envelope with encoders is not really practical: you could plug a joystick in the Aleph instead to do the job - I’d do that through MIDI with the remote from my Kurzweil KSP8, for instance. Then if you need envelopes it’s all about finding the right time and amplitude scale. And wouldn’t you like your envelope to be linked to an amplitude follower of some kind, in order to make it better than a looped change of levels?

[glia]

Good points

If youre helping, feel free to start with what makes most sense in your setup…i can tweak it for my own use if it doesnt directly fit

For me the idea is similar to working with the autowah effect on a roland sp (or this ) so using the encoder for shaping would be a familiar control gesture

I spent most of the day thinking of how best to map controls and am still not sure . to make this intuitive might be a LOT more work than i was planning but I think it will be worth it

My latest thinking is to display a flat line representing the untouched envelope at startup. X axis represents amplitude and Y is time (decay?). First encoder will raise or lower the attack on the X, second encoder does the same for release. Fourth encoder stretches or squeezes the length of the whole envelope…holding SW 1 while using this ENC will only affect the length of Attack (SW2 + ENC will affect Release).

I have other ideas for the third encoder and other buttons but this would be more than enough fun if i got the basics working properly

[glia]

totally dropped the ball on this last weekend

I’m just talking aloud in case others can feed off the ideas: having a grid again might dramatically simplify the basic input

[Yann_Coppier]

indeed. Less precision but faster workflow… I’ll look into it, for sure but I have to start from scratch, as I accidentally erased all my Loom sessions - and I had a lot. No big deal, it’ll just take a bit more time… right now I am stuck into Grains I must say, and it is awesome!

[Andrew_Sblendorio]

In response to your post about the direct visual output, what are the possibilities with the ii protocol? I don’t know anything about it…would it be possible to send visualization data from there to a computer or to convert that data somehow to send to a screen?

[Yann_Coppier]

That last message reminded me of the existence of Loom. I will back to it now, and will try and make it work with the last version of Bees I got. I have an idea that something fun is on its way.

[glia]

No idea

Don’t have the time/skills to tackle this but the first place I’d look are the upgraded serial ops. There should be a way to print the data being pushed to screen even if some conversion takes place in between devices and applications

I’d love to see the results if somebody figures this out!

[zebra]

clarification:

aleph i2c and serial aren’t related. ‘serial’ refers to using the usb device port as a tty stream with a host computer.

we include i2c code modules in the aleph avr32 library. they have been tested, but aren’t used in bees or in the default application framework.
[https://github.com/monome/aleph/blob/dev/avr32_lib/src/i2c.h]
[https://github.com/monome/aleph/blob/dev/avr32_lib/src/i2c.c]

this is just because when aleph was made, the monome euro ecosystem didn’t exist, there wasn’t any i2c hardware that we actually wanted to talk to, but we though a use case would come up for it eventually.

i desparately need an uninterrupted month or three to finish the aborted initiative of refactoring aleph to use libavr32 and bring it up to date with its cousins.

[glia]

aleph i2c and serial aren’t related. ‘serial’ refers to using the usb device port as a tty stream with a host computer.

Great point. sorry if i gave that impression and muddied the waters.

Even though he asked about ii my mind jumped to the existing serial link (seemed like a more logical option…could be wrong tho)

[zebra]

you’re absolutely right, sorry i should have looked at the context more closely.

yea, if you want to send data from aleph to a computer you would use the serial usb port.

‘ii’ is a shared data bus for multiple devices, its message-based instead of stream-bnased, and it makes most sense for small payloads on ad-hoc networks of devices

[glia]

yep

i desparately need an uninterrupted month or three to finish the aborted initiative of refactoring aleph to use libavr32 and bring it up to date with its cousins.

i’d squeal if you complete it!