#121

Both are fine to me, to be honest, so I guess it’s all about what you can hear or not. If it makes a significant difference in terms of sound I’ll always go for quality instead of quantity. Then again if there is no audible difference, why not use 65 seconds indeed? By the way, could you implement something like that in the Grains buffer as well?

Ah also, I don’t think we should aim at keeping the scene compatibility systematically, as it will make Bees heavier and heavier (having two versions of the Grid objects, for instance): version 0.8 will be a big step forward, and we should all take advantage of its potential by developing new stuff and eventually porting the old on it, which shouldn’t be too difficult.

3 Likes
#122

Like, a single extra integer param which acts as a global multiplier for all of lines’ ‘time params’, enabling integer multiple of 32.8 seconds total length? Sounds workable to me!

1 Like
#123

yeah exacerly. like on i dunno, a boss dd-20 you can set “meter” which just multiplies the tap.

does it even need to be an integer?

#124

cunning! mul/div representation or 3.12 fract representation?

#125

I know these are scene breaking due to param name switch but I dont really have a problem with the switch (my scenes were broken anyway)

Open to anything but prefer the idea of long buffers.

#126

i would lean towards fract. whatever radix would max out SDRAM usage for the buffer sizes. that’s exciting, we haven’t really tried it before…

1 Like
#127

buffer load/save to sdcard feature for 0.8.1 then? (what am I saying, this is crazy talk!) I think it should be done as a BEES page with a list of 32-bit .raw files - just duplicate the modules page for UI, but dump as much of module audio SDRAM as can be transferred in, like 20 seconds, to/fro sdcard. Isn’t this actually a pretty straightforward little hack?

Putting that thought on hold for now, I calculate the right radix for time-scaling param is 2.13. With this new scheme, max loop length for each line (at 4ms worst resolution) would be just over 2 minutes. Much more of a win-win!

2 Likes
#128

i know @Test2 got something working with streaming audio files from sdcard, for prgrm. i lost the link to the thread about it…

i do remember it was slow. and then i saw this awful thing:
[ https://github.com/monome/aleph/blob/dev/avr32/src/interrupts.c#L75 ]
(a very long delay in the PDCA interrupt. i really hope that’s not actually necessary. no wonder it takes so long to save/load scenes)

really making me want to strip down preset/scene size to fit at least one in nvram.

#129

really good conversation on this! really glad to finally have this sorted (believe it’s sorted now - just added the time-scale param to lines).

since we’ve agreed to break scene-compat for lines I feel like we could very easily free up quite a few cycles in lines by making the filters either low-pass, high-pass, bandpass or notch & using the ‘label’ param-type so it displays onscreen as a filter-name, not a number. The code can be copy-pasted from acid’s monosynth voice so this is an easy enough change. Would everyone agree with this decision? Or are people using the existing feature for no-input-mixing techniques fading gradually between filter types?

I thought this could free up enough bfin cpu time in lines to do, for example, linear-interpolated reads on one/both channels. Or make write heads fade in more cleanly on recording start. We should be able make these improvements in 0.8.1 without breaking 0.8.0 scenes if we change filter params now…

scrub the suggestion on modifications to lines’ filterbank… lost perspective there on the overall direction, sorry for the line noise…

I didn’t mean to get sucked into a major overhaul of ‘lines classic’ - the original design is fine apart from that stupid timebase incompatibility thing. It can definitely do the ‘beatslicing loop pedal’ thing now (along with the multitiude of other things it already did/does)

2 Likes
#130

about buffer recall, with some luck the changes made for prgm and block could be used in bees too, I can make a pr that sums it up, iirc I did remove that long interrupt delay, and several others…

5 Likes