#21

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?

1 Like
#22

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?

#23

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

#24

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?

#25

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

#26

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

#27

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!

1 Like
#28

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?

2 Likes
#29

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.

2 Likes
#30

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!

1 Like
#31

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.

1 Like
#32

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)

#33

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

1 Like
#34

yep

i’d squeal if you complete it!