#41

thanks…i’d be happy with just one extended buffer along with filter/eq params

how about that for creative limitations? (tell me what you think…is this doable?

#42

[quote=“rick_monster, post:40, topic:177”]
Then record some sound and quickly flick writeEnable to 0. the last second of recorded audio should now play on a loop - you can trim the loop using echoMin/echoMax, speed it up/down using echoSpeed, change the pitch with the scrub params…
[/quote]cool

i should be able to get momentary control with an FS, right?(enable - down, disable upon release)

#43

Can you describe in more detail what you mean? Extended buffer with filter & eq sounds quite a lot like lines to me! I added param reading to bees, so if the sample length is set by punching the DSP in & out, BEES can read the recorded length back from the DSP after punching out, then trim a sample like that. Only shame from a technical point of view is we don’t currently have true callbacks from DSP to avr32, so there’s no way to, for example make the sampler bang bees net every time it repeats. That would be kind of cool!

Personally I’m hot on the idea of including the pitchshift/timestretch from grains to mess around with performance-sampled arpeggiator patterns. So a sampler module could have 2 options for pitch control: semitone-tune & A / B (where A is a real number, and B is an integer).

Yea - but obv it can get a bit confusing if the read-head is in different position from the write head - also you need to do some extra bumff like measuring the button press time in avr32 time units, then converting to the right time units for grains. I strongly object to this bad hack, but probably matters less for ‘sampler’ functionality as opposed to ‘loop pedal’ (where loops can be a minute long, whilst being highly accurately timed) …

#44

[quote=“rick_monster, post:43, topic:177”]
Extended buffer with filter & eq sounds quite a lot like lines to me!
[/quote]yeah I somewhat agree but I think the main tradeoff I’m interested in is dropping one buffer and using that dsp power on something else (not even sure what)

[quote=“rick_monster, post:43, topic:177”]
Personally I’m hot on the idea of including the pitchshift/timestretch from grains to mess around with performance-sampled arpeggiator patterns.
[/quote]I agree with this totally

#45

well anyway, sampler module needs quite a lot of thought, planning and most importantly decisions, whereas voder-clone will be more of a quick, fun hack! I think the aleph ecosystem would benefit more from a few more simple fun-hack type of projects, rather than labour-intensive crazy, hard-to-understand things like grains…

Grains aims to morph between sampler, chorus, pitchshift, flanger, karplus-strong, echo-box. Having explored most of the ideas & DSP tricks that unify all these effects, it seems to me that the two which should really have their own dedicated module are sampler & karplus-strong. Other ‘easy’ ideas I’m toying with are ‘beep-box’ (random, ever-expanding collection of unflexible sound-widgets to hook up to op_ww or whatever, including cheez-o-matic digital monophonic synth) & a four-op classic FM synth (pretty sure @zebra already did something like this, but it’s not currently working afaik).

Personally, I’m excited that in aleph, we have open-source, hackable, patchable versions of, old chestnuts such as pitch-shift guitar pedal. I want to escape the trap where it feels like aleph modules have to be something ‘new’ and/or esoteric…

slight tangent based on your suggestion there - how about ressurecting the idea for ‘414’ (aka four-track tape app) as ‘line’ - a single fractionally addressed (i.e variable-speed) lines-line with extra bells & whistles? Note - I would definitely put this in the category of crazy/conceptual/open-ended! All sorts of sticky questions and little puzzles - overdub/overwrite? variable-speed write-head? If there’s any cycles left, do you randomly tack on some primitive sound-generators to this ‘everything’ module?

1 Like
#46

[quote=“rick_monster, post:45, topic:177”]
I want to escape the trap where it feels like aleph modules have to be something ‘new’ and/or esoteric
[/quote]TRUTH

I cant agree more…hard to explain but the beauty is in the open control and quick transformations from one box to another (not really the size or scope of each)

#47

excellent points cause i dont really know what i want in a sampler but the tape machine is easier to articulate:

4 tracks
destructive edits = no overdub
global pitch speed (not per track)
pan + two band eq
i/o routing

keep in mind i’ve not used a 414 when i say all this but, features could be added after the basic elements get hammered out

#48

also i’d say in the short term a dedicated fm synth would appeal to me more than mono, karplus, or sampler

#49

also since ezra mentioned he default and maximum frequency response in another thread i’ve curious…

what is the computational disadvantage to a module using 192k? could we do a reverb of some sort (even if the guts are essentially delays similar to what we use already in grains/lines)?

#50

well tape-machines are much of a muchness I guess! The trouble with the original idea of ‘414’ module is that there are some tough technical questions how to get audio data on/off the SD card within the framework of bees. My thinking is 4-track should also get it’s own app, rather than tacking something onto bees.

Variable-speed writes are a little tricky & inherently ‘bursty’ (they will tend cain the cpu when you write at higher tape speeds). Plus that code is not written yet, so I don’t quite know how it goes…

All in all I don’t put this project in ‘weekend hack’ category, so will probably shelve it for now - actually got a basically functional rig for the first time in ages and having fun making noise with it, hence don’t want to go totally nuts again with open-ended projects and neglect music-making…

Gonna write down all the ideas tonight, pick the quickest one & try to hack together a version before the end of the week. Did a load of work on dev tools for aleph DSP - it’s time to put them to the test!

1 Like
#51

On the 192k question - for single-sample processing 192k would be 4x more cpu-intensive than 48k, plus you’d run into even more trouble doing slow slews. Block-processing the water’s more murky, but still high bitrate will eat cpu…

I think aleph sound-quality bottleneck is random digital noise bleeding into the signal path. In fact I’ll probably be moving future aleph DSP dev to 16-bit processing to save cycles. Some stuff (like filters) may need 32 bit for reasons of numerical stability, but things like read/write delay lines should probably all just be 16 bit…

In my opinion we’re not at a level of fidelity where it makes the blindest bit of difference whether you’re running at 24bit/192kHz or 16bit/48kHz, so personally, I wouldn’t bother.

1 Like
#52

cool i can respect that

#53

I did faff around a bit with allpass-ring reverberators in common lisp. Pretty fun - needs lots of tuning to sound ‘right’. You hook up 5-10 allpass filters in a ring, squirt sound in somewhere in the ring, read it back out somewhere else.
https://ccrma.stanford.edu/~jos/pasp/Allpass_Two_Combs.html

Back on the esoteric side I thought a cool ‘digital instrument’ could be some kind of array of 4-or-so karplus-strong-strings somehow ‘attached’ to an ‘instrument body’ made of allpass resonators. An imaginary digital banjo thingy. The strings can feedback into each other through the allpass network - I wonder how it would sound! Guess this is a kind of waveguide synthesis?

EDIT:
Hummm - just re-read your post & I dunno if there may be other benefits to higher bitrates for synthesising reverberators. Sometimes (like with digital filters) you need to calculate at much higher accuracy than incoming/outgoing data stream…

1 Like
#54

absolutely agree, but there is a different reason to use high sample rates, which is to reduce aliasing

1 Like
#55

ha - yea ok so I guess it’s actually cheaper to simply run the sample clock at higher speed rather than upsample/downsample in software - cool!

1 Like
#56


Interviewer: About how long did it take you to become an expert in operating the Voder?
Miss Harper: It took me about a year of constant practice. This is about the average time required in most cases…

UPDATE:
Basically working version of Voder achieved over the weekend - some kind of Voder emulation basically done, though still need that year of practice before conversing fluently like Miss Harper… Also tacked on the Vocoder functionality where the ‘keys’ are operated by 8 envelope followers operating on 8 bands of the formant. Still needs a bunch of tweaking, a sensible mixer section & an extra bfin param to scan between manual keys (Voder) & formant measurement (Vocoder). Code is here it’s currently hardwired to ‘vocoder mode’:
https://github.com/rick-monster/aleph/tree/dev/modules/voder
comment these lines to go into ‘voder mode’:
https://github.com/rick-monster/aleph/blob/dev/modules/voder/voder.c#L246-L249
Aleph input 1 currently hardwired to mix in a carrier wave, Aleph input 2 currently hardwired as formant in vocoder mode.

Binary release to follow when it’s a bit more polished. Too many other fun ideas I want to try out first before trying to finish off properly, start a dedicated thread, record a demo, write instructions etc. For now go grab a sneak peak from teh githubz.

The main point I’m especially pleased with is the ‘polyblep’ antialiasing for saw/square waves. It was tough to nail this thing down in fixed point arithmetic but really hit home the importance & power of the bfin emulator approach when working on nontrivial new DSP blocks.

3 Likes
#57

Can you elaborate on that? I do not own an aleph, just interested.

#58

For example, listen through headphones to the output from my grains module, then attach a grid & turn on all it’s lights somehow. You will hear some strange humming/buzzing sounds, which get a lot quieter if you crank the headphone volume. I believe it’s some crosstalk from aleph’s digital circuits into the analogue signal path.

Not been working much at all with headphones recently so a slightly noisy device doesn’t actually bug me. In fact the aleph main outputs may even be less susceptible to this noise - should really measure properly at some point, but it’s not something bothersome listening at reasonable volumes through my apartment’s sound system so I don’t care, mainly interested in hacking on DSP & making music!

Anyway these slight aleph hardware niggles aside, my point is that in order to get real 16 bit / 44.1kHz sound (i.e a 0-22kHz bandwidth & 90dB SNR) you have to be incredibly careful about ground loops & signal integrity at every point in your signal chain. Unless you’re the type that gets crazy measuring noise floors with an audio precision or other accurate test equipment, the tiny benefits of running an aleph in high-def audio will probably be lost.

Currently most of my aleph code does all it’s audio processing in 32-bit accuracy, and I believe we could squeeze a lot more interesting sample-by-sample processing out of the device by doing more of the bus-ing, mixing, interpolation & other processing in 16-bit with no perceptible signal degradation. @Yann_Coppier noticed some strange high-frequency artefacts caused by grains ~ 80dB down or so IIRC. This is more the kind of thing that will contribute to ‘bad digital’ sound…

Having said all that I totally agree with ezra’s point that higher samplerates reduce aliasing noise, so for something like FM synthesis probably there would be some reasonably noticeable benefit to running at higher samplerates. However for subtractive synthesis I discovered polyblep algorithm this weekend which nearly eliminates aliasing noise from square/saw oscillators @ 48kHz (see Voder project).

1 Like
#59

On the topic of noise, I’ve found the noisiness of headphone driver to be very dependent on the headphones which are plugged in.

With a pair of Sony MDR-7506 plugged in I can hear bleed from the first two inputs when a strong signal is passed in, the inputs are turned all the way down, and the headphones are turned all the way up. I haven’t noticed that same bleed in the main outputs.

With a pair of AKG k601s plugged in and the above scenario I don’t recall hearing the bleed - then again my hearing may well be shot. Either way the headphone amp bleed that I’ve experienced hasn’t slowed me down much now that I know that it’s there and that I don’t need to worry much if at all about the outputs in practice.

#60

finally found some time to mess around again with my avr filename dilemma! found that file load works when fs_dir_ent cluster is an odd number and it fails when its even, is there some documentation on cluster values and how they are set?

1 Like