#230

Oh! great, thank you!

#231

Really liking the 0.8 bees!
Looking for a bit of help/insight on lines

I’m trying to first of all create some sort of delay line that I can scrub through in a granular fashion
 It should be simple, but I’m running in to a problem, when I want to start scrubbing.
I just use one delay line so far, and I write to it from an input. At the push of a button I set write0 to -inf, and then i manipulate the pos_read0 to scrub around the audio.

But if I want really short grains/repeats, I thought of just making loop0 very short
 but then the “play head” also wraps around.

I then tried having loop0 to max value and a metro banging on my encoder value sending it to the the pos_read0, but the metro doesn’t really go fast enough. Has anyone implement something like this that works or has an idea of what to do? Should i just do it in grains instead? Haven’t worked to much with grains yet, lines seemed easier to grasp.

2 Likes
#232

that’s the way. 200hz isn’t fast enough?

you may find grains more in line with your intentions

#233

Well, grains features very short delay lines for the moment, although I think this feature should be enhanced soon. But far from the 32 seconds of Lines, really. So what you get on one hand, you lose on the other
 Also, Grains is modifying the sound quite a lot more than Lines, which I think is fine but well, depends on what you’re after. Still my favorite module so far!

1 Like
#234

Yes, actually for what i wanted to do lines definitely works best, as I wanted do some very short resonating delay/high feedback-thing, that i could then freeze and play around with
 And for that lines just sounds better, as it obviously is a more straight forward delay. But maybe the 5 ms retriggering will be okay. Tried it with grains, and resonant short delay/high feedback sounds good there, it isn’t exactly the same thing.
But yes I can’t get everything i want, but maybe thats not to bad. It definitely is making some cool sounds


#235

revisiting some of the tutorials of yore but there are some critical images of block diagrams missing (404 error)
 .png files and .jpg files

it seems to only be tutorial 4 & 7 for me
https://monome.org/docs/aleph/tutorial-4/
https://monome.org/docs/aleph/tutorial-7/

anybody else experiencing this?
anybody have these diagrams?

i foraged through the old forum (that was a trip!) as well but found nothing

#236

Archive.zip (517.0 KB)

is it what you’re looking for ?

#237

Actually I would ideally like “t4-rand.png” as well as “t4-sah.png” and “t4-rand2n.png” from tutorial 4

#238

I’m a little bit confused about using the rMul and rDiv parameters in lines.

If I change rMul from 1 to 2, shouldn’t that just make the delay/loop happen twice as quick, since it’s reading twice as fast? Or is it not that simple because it is not also doubling the write speed? I’m also wondering the same thing about rDiv, shouldn’t that make the delay/loop happen twice as slow? I seem to be able to get the right results with rMul, but I cannot get rDiv to halve the time. I’ve tried many combinations of doubling and quadrupaling the loop time relative to the delay time to try and compensate assuming the write speed is the same but I can’t get any to work.

Also when I switch these parameters and go back to 1, it seems I always have to readjust the delay time, it seems like the read and write heads lose sync.

Thank you

#239

in “classic lines”:
setting the “delay” parameter literally moves the read head (with crossfade) to the appropriate position relative to the current position of the write head at that moment, and takes no account of the read head speed. the write head speed is fixed at 1.

the “loop” parameter essentially shortens the length of the buffer. read and write phasors are hard-wrapped at the loop point, with no crossfading. so yes, with rMul=2, the read head will go from 0 to the loop point in half the time.

so if you want a “granular delay” kind of effect, with pitch shfting from rMul/rDiv, probably the best way to get it is to set a metro to repeatedly bang the same value to the delay parameter.

if you don’t do this, and change rMul/rDiv, the read and write heads will soon drift out of sync.

1 Like
#240

Thanks,

So I created a metro, enabled it, set the period to 500 and value to 500.
Metro/tick > delay0
rDiv0 > 2
loop0 > 500

I still seem to be getting some kind of phasing, when I play a note the delay time is not consistent. It gets longer and shorter, seemingly in a phasing motion.

The effect I’m trying to achieve is a delay with a consistent timing where the echo is an octave lower than the input. Just to be clear.

#241

don’t use the loop0 parameter. leave the loop at something large. it is your buffer size. the metro is basically your “looping” method, and having two “looping” methods overlapping each other (one independent of phasor speed, one not) will indeed cause complex/glitchy effects.

the metro value corresponds to your echo time.
the metro period is how often the read head is “re-synchronized” to the echo time. if you think about it, you can’t have an echo with pitchshift without such a “re-sync” method, and without losing some information (in the case of down-shift):

lets say your input is: ABCDEF
 - each letter is some input audio occupying a unit of time, like 1/4s. you re-sync every 1/2s. your output at 1/2 speed is: AACCEE


in other words: yeah, in between re-syncs, the delay drifts out of sync; since you have requested the read/write phasors to run at different rates, it can’t be any other way. so pitchshifted echo (in the simple, time-domain sense) can only be “granular.” the metro is “generating grains.” i would experiment with modulating and/or randomizing its rate. (also with the fade parameter)

the grains module is a little more sophisticated for this kind of stuff.

#242

Thank you.

You know those nights when you’ve gone on for too long?

Anyways, I made some little charts with numbers lining up normal beats and halved and doubled beats, and am starting to see the math not adding up. If you double the speed you use your buffer up twice as fast, and if you halve you use it twice as slow, and you run out.

#243

How does order of operations work in bees?

It seems that each individual operator outputs from top to bottom, although I’ve only examined this closely on the grid classic operator.

How do things proceed from there? Is it similar to how in max you follow the first operation to the end of its particular network, then you follow the second operation to the end of its particular network? Or does it work some other way?

#244

Also, has anyone tried to set up the development toolchain on linux lately? I am having trouble getting the avr32 toolchain up and running. I did it a couple months ago without trouble, it looks like the atmel site has changed/has been gobbled up into this www.microchip.com thing


Anyways this is what I’ve been able to find for the toolchain:

https://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers)

but I cannont find seperate header files anywhere. It seems that under avr8-toolchain/avr/include there are some header files, maybe not all of them? Maybe not the right ones?

Thank you

#245

just so that understand correctly, are you getting these errors when you are running the make command?

#246

No, I haven’t tried to make anything yet.

I’m just working through the steps for development setup on the readme under the main aleph repo: https://github.com/monome/aleph

I am trying to get the AVR32 development setup working on linux
 the link here doesn’t work:

currently the page is here, (but it could move) [http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx] you will need to sign up / login.

#247

edit, removed links.

I’m not at my computer atm, so I’m afraid I couldn’t verify but


maybe one of these links or is that just the links you already got?

1 Like
#248

your assumptions are correct

#249

these indeed look to contain the needed stuff for building avr32 firmware.

@Andrew_Sblendorio just to be clear, you don’t need an avr32 toolchain to build host-side stuff like the puredata wrapper, only to build the device firmware itself.

1 Like