#7

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…

#8

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.

#9

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…

#10

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…)

#11

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().

#12

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.

#13

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.

#14

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:

#15

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
#16

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!

#17

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}
#18

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…

#19

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!

#21

Doing a no-input aleph set? :wink:

#22

i’m hoping to put another release together later this weekend. the day job has been all consuming…

…maybe lines needs a new parameter to toggle on the writing of random bits to one of the delay lines :smile:

#23

it’s that very very special patterned/unpattened noise of unitialized memory! why does it sound like that??

also, why does modem noise sound like fractal noise ?? ( x[n+1] = a*(x[n])^3 + (1-a)*x[n] )

mysteries

1 Like
#24

ha, yes, sometimes the noise would throw me interesting moments of unpredictability. One of my favourite things in lines is when i change the loop length on the fly via an encoder. starting it long while recording, then gradually reducing it, and then turning off the recording or going into overdub, so when you extend it again you get a collage of fragments from earlier recorded loops . . .
hmmm, that now reads like a fairly incomprehensible description! try it though :slight_smile:

2 Likes
#25

i know i’ve asked this before or figured it out and forgotten

how do i download files (like the new lines) if they arent in the zip?

#26

go the the “releases” page:

#27

yeah sorry
wasnt paying attn that it was already rezipped on 718 with everything else

easy