Aleph update - bees 0.6.1, lines 0.2.2

note: this release has been superseded by:


updated software for the aleph is available on the releases page:

details on updating can be found here:
http://archive.monome.org/docs/aleph:updates

the primary focus of this release is increased stability when loading scenes but there are some additional features:

bees:

  • added op: SHL, SHR (bit shifting)
  • added op: CHANGE (filter repeated values)

lines

  • enabled clearing of buffers on load

note: for those updating existing SD cards be aware that the dsp module names have dropped the aleph- prefix. in order to ensure the latest dsp module builds are used it is recommended that existing copies of aleph-lines.*, aleph-dsyn.* and aleph-waves.* be removed for the mod directory on the SD card. existing bees 0.6.0 scenes should work without modification (even with the module name change).

also thanks goes to @tehn and @zebra for helping guide the way

5 Likes

hi hi,
so been playing with the new lines and found a little weird behaviour.
If i load an old scene I created with previous version of Lines all is good.
but if i start with a clean boot and then load lines i get loads of strangeness.
if i save and then try to recall the scene it hangs on ‘sending parameter values’. So I unplug and clean boot.
To get around problem I have to load an old scene (during which i see ‘aleph-lines’ in the loading screen) and then load up one of the new scenes I have created.
I thought it might be something to do with the fact that all the default parameters of lines (e.g. fades and slews) were all set to zero but I tried changing that and same problem occurs.

also if i create new scenes with the new lines from clean boot i get some problems with rMul and rDiv not working. though this is hard to replicate reliably, still investigating.
I’m uploading a zip with 2 files as example ( clear.scn is from the old lines, newDelay01.scn is created with the new one)
can anyone replicate effect?
alephissues.zip (3.5 KB)

I’ll see if I can replicate the problem.

Out of curiosity do you have both the old aleph-lines.{ldr,dsc} files and the new lines.{ldr,dsc} files in you mod directory or just the new files?

I’ll go back through the revision history since the aleph-141106 release just to confirm there weren’t any changes other than the dsp module naming and buffer clearing.

no, just the new files in there.

i think the main difference is that the parameters are now all set to zero when you load it, whereas before they all had default settings (e.g. slew times for fade, filters, loop length)

ah, i’ve also just discovered that the filters don’t work (on old or new scenes) -
if you set wet to 0db (and dry to -inf) the only way i can get sound from the buffer is by turning up the hipass or bandpass level, but the audio is unaffected by the cutoff setting (no sound out of low pass)

Argh. Something is going haywire with the parameter defaults when lines is loaded after bees scene has been cleared - I’m currently at a loss as to why this didn’t show up during my development and testing. I’m beginning to wonder if all the renamed modules are effected (my guess is yes).

I can see that the module name isn’t getting set correctly in new scenes, both your newDelay01_.scn and a test scene I created think the dsp module is called just .ldr not lines.ldr as it should be.

Looking through the commit history of lines I can see that only real changes to lines between version 0.2.1 (included with the bees 0.6.0 release) and 0.2.2 (included with the bees 0.6.1 release) are:

  • the “standard” dsp modules lost the aleph- prefix
  • the buffer clearing code in lines was enabled

My suspicion at this point is that there is another bit of code which is assuming that the dsp file names match the internal name reported by the module itself (will need to confirm that with @zebra)

Given all this:

  • I’ve marked the alpeh-20150619 release as “pre-release” on Github
  • I believe you can revert to the dsp modules included with the aleph-20141106 release for now.

I’ve confirmed that if I use the previous aleph-lines.* files (version 0.2.1) with the new bees-0.6.1 release the parameter defaults are getting set correctly so that points to some additional problem that was introduced back when the module rename was done.

I had thought that the module rename change when out with the bees-0.6.0 release but apparently not…

ah ok, (i’m assuming i can’t just change the filename of lines 0.2.2 to aleph-lines? this may be a dumb question)
the buffer clearing is making my life so much better!!! i’m preparing for some new live shows this autumn and the ability to swap scenes without having to worry about muting mixer channels is awesome.

here’s the rename commit
665b0a008df9dc7ab088b9a620d62400992d8e05
it was included in bees-0.6.0 and not before, as far as i can tell (from running git tag --contains)

i’ll try and take a look…

so am i correct in thinking this problem only happens when you trigger the load of a DSP module from the DSP menu page?

and one symptom (A) is that you get a blank module name stored in the scene data?
and another (B) is that the bfin doesn’t respond correctly to parameter chagnes (presumably the descriptors are scrambled)?

i would try skipping the call to scene_query_module() here:
[ https://github.com/tehn/aleph/blob/master/apps/bees/src/pages/page_dsp.c#L163 ]

(in fact scene_query_module() should probably be retired altogether at this point; all DSP loads are triggered in such a way that we already know the module name.)

see if that fixes symptom (A).

however, i think symptom (B) can only be attributed to a failure of files_load_desc() earlier. ( which is in turn called from files_load_dsp() )

dumb question: are the .dsc and .ldr files present and in agreement on the sdcard? (edit: i see that they are there in the release tarball…)

just did a quick test, commenting out that line. Loading lines from a cleared scene does appear to contain lines as the module name instead of .ldr. I’m noticing that existing scenes include the module name including extension (i.e. lines.ldr) so there is probably more investigation that needs to get done.

…with the call to scene_query_module() commented out the parameters are being defaulted to values which are non-zero however a the defaults don’t appear to match between lines 0.2.1 (aleph-lines.ldr) and lines 0.2.2 (lines.ldr) so it looks like we’ll need to dig deeper into what is going on in files_load_desc().

believe it or not, this is by design (sort of.) one of the requests for 0.6.0 was for the DSP page to hide filename extensions. so they are just stripped off in the list in files.c. the module-loading routines strip off the extension anyways, so it shouldn’t matter whether it’s present in the scene file or not (and last i checked, it didn’t matter in practice.) i think the only time you see the extension in the scene data is when the scene was created from an earlier bees version.

anyways none of this explains why the parameters are screwed up, which is the main issue. you may wonder why clearing the audio buffer in lines wasn’t done in the first place, and the fact is that i did try adding that and ultimately just had to revert it because it was causing weird initialization-time gremlins (whether using memset() or a loop over samples.) we may be seeing a resurgence of these.

i just got to my studio and can actually look at the hardware now, so maybe i can get some more answers tonight.

Sure enough. Loading old scenes with the buffer clearing memset() call in module_init() then things seem okay because I gather the initial parameter values are coming from the bees scene itself. When explicitly loading lines into a clear scene the parameters are getting initialized to their respective 0 value - removing the buffer clearing logic results in parameters getting initialized to their defaults. Strange indeed.

Good thing I caught this thread - was just about to update before heading out on tour later this month, will hold off.

Just a quick note from a non-programer: I could definitely live without manual buffer clearing in lines if it didn’t blast noise on start-up. :sunny:

Update: It looks like we’ve found and fixed what was causing the parameters to not get initialized. Some additional testing is warranted before putting a new bees build up - hopefully soon.

1 Like

after updating my aleph to 0.6.1 + lines 0.2.2 I had an issue where the incoming signal would be (i believe) clipping in lines. i tried investigating the parameters and inputs but couldnt find the issue. i am not well versed in lines though, so the problem could have been before my eyes.

so, i went back to lines 0.6.0 and the issue was solved. however, now i am finding that none of the modules load. when trying to load lines it hangs on “loading module”, doesnt freeze but also doesnt load. same issue with other modules.

any tips/advice from the community would be very appreciated!

Was this a new scene or an existing one? The only change in lines 0.2.2 was the buffer clearing which wouldn’t effect whether or not the incoming audio was clipping. What could be a problem is if started from a blank scene and loaded lines as @dspk did - that combination will lead to all the parameters to lines getting set to 0 (yielding no sound by default) or random values.

By going back to 0.6.0 do you mean that you took the scene which was created with the lines module named lines (no aleph- prefix) back to an SD card with bees 0.6.0 and the lines module named aleph-lines? If so then yes I can imagine it hangs loading when loading a module (internally the scene refers to lines the new name but since only aleph-lines exists on the card it gets stuck).

Getting going again would involve one of:

  • recreate the (0.6.1/lines) scene with the previous bees/aleph release
  • hexedit the scene file and change lines to aleph-lines
  • duplicate the aleph-lines.* files on the card creating lines.{ldr,dsc}

with 0.6.1 i tried existing scenes ‘skitter’ and ‘space’. i was however getting sound (albeit distorted) which i assume meant the parameters were not set to 0? i havent investigated further since then, so maybe i’ll look into it again in the next couple of days.

so what i did was i deleted 0.6.1 from my sd card and reloaded 0.6.0. this “solved” my problem of clipping/distorted signal.

however, the next day i attempted to load the same existing scenes but it would freeze upon ‘loading module’. as such, i tried ‘flashing’ 0.6.0, or, reloading what was still on my sd card again via the bootloader. this did not solve my problem.

i then deleted 0.6.0 from my sd card and reloaded onto sd card, loaded it onto aleph and everything seemed fine again. but last night i turned aleph on, it loaded my default scene which is in waves just fine, but then i tried loading lines and it started freezing again when trying to load lines. essentially the same problem i had before…

yes if you use lines-0.2.2 right now, you are likely to get random parameter values on initialization. this is a bug exposed by clearing the lines buffers during init, and it is the reason that said clearing wasn’t previously being done. @ngwese among his other much appreciated contributions, has found the race condition that caused this bug; it is now fixed in the development branch and will soon be rolled out as a new release tag.

to clarify: that behavior is coming from interaction between the lines-0.2.2 DSP module and the current/previous versions of bees (0.5.x, 0.6.0, 0.6.1, doesn’t matter). you can use lines-0.2.1 instead, in which cause you may trade the random parameters values for weird weird noise on startup, or you can build a new bees from the dev branch on github, or you can wait for the next bees release (which will probably be called 0.6.3.)

in general, bees 0.6.1 will be much more stable than 0.6.0 as far as crashes and hangs, so i’d recommend sticking with it.

on a personal note, i kind of miss that horrible noise. i had come to rely on it!

Doing a no-input aleph set? :wink: