#142

I didn’t notice, but anyway that is precisely what I am using it for as well. It could be nice to include it in saved scenes as well anyway. No need for BIGNUM anymore! Also, I was trying to use Kria again and was reminded of the stuck Alt button, which makes the whole object almost impossible to use (once the button is stuck, each time you want to work on the length of any loop you lock it to one step, for instance). Have you noticed it as well, or is it only me?

#143

yea I’ve fixed that bug! but haven’t found time to re-release binaries. If you have a working toolchain you can just change line 473 of ops/op_kria.c from:

key_alt = 1

to

key_alt = 0

there’s only that & one other tiny bug I found/fixed since last binary ‘non-release’. I actually will have the proper time/headspace in coming weeks to dedicate to playing around with the device, exploring the already-huge creative possibilities, fixing bugs, refining module ideas etc…

Actually I would like to open a pretty broad discussion what sucks, what rocks, fanciful ideas that always sounded cool! For example did anyone find the new ‘varispeed lines’ to be a useful creative tool? Any suggestions how this module could be adapted/developed now we have working code for interpolated buffer read/writes?

#144

Ok @skektek I did it, and it works. Thanks!
On my own I have added ROUTE2 and HIST2, which I have used for some of my Scenes. ROUTE2 is practical when working with LIST2, for instance, and it saves some outputs for big scenes. HIST2 I used mostly to compare a value and the one preceding it. Again saving some outputs. Should we add them to your next release?

I have never been a big user of Lines, mostly because of the non-varispeed aspect of it. So I am not the one to tell you much about it at this stage, except I might start using it a lot more now.

I also have tried to jump from WW to Kria to Step to MP, all ran by the same METRO. It is perfect, really nice to see (and hear) them working at the same time!! Just so people know, the way to switch using one single button is to use a THRESH operator on a switch, for instance this way (here with KRIA and WW only):

SW1/VAL -> THRESH/IN (with LIM=1)
THRESH/LO -> ADD/A (with B=1)
THRESH/HI -> WW/FOCUS
ADD/SUM -> KRIA/FOCUS

Otherwise the last of your two sequencers in the chain will shut after the first one opens up, overriding it and therefore ending with nothing on your grid. Once it is working it is quite a joyful experiment !!

#145

Ok so I have just encountered a rather strange bug, linked to MUL and METRO but not only. Maybe you have seen it as well then? Try this:

ENC0/VAL -> MUL/A (B=1, TRIG=1)
MUL/VAL -> METRO/PER
METRO/TICK -> WW/CLOCK

If you then modify MUL/B, no matter what you do (let’s say you change it to 2, or even 0) the period of METRO goes to 5, and turning ENC0 won’t change anything - putting up the period directly on the input page will work though. Note this is only the case with MUL/TRIG=1 and there is no problem whatsoever with ADD, for instance. Now it does the same with STEP instead of WW, and you might even wonder why I am stating this… Well, it’s because without a sequencer attached the issue disappears.

My idea was to modify the period from within a sequencer, which I used to do with STEP long time ago and without any problem. When I tried the whole thing started blinking like crazy, and after a while I found it. Any idea about where it comes from?

Edit: in the METRO object I found a modification, line 136, going from “net_activate(metro->outs[0], metro->value, &(metro->super));” to “net_activate(metro, 0, metro->value);”

Same, in the MUL object I found two modification on line 62, going from “net_activate(mul->outs[0], mul->val, mul);” to “net_activate(mul, 0, mul->val);”, and on line 71 from “net_activate(mul->outs[0], mul->val, mul);” to “net_activate(mul, 0, (float) v);”. Unfortunately I can’t tell if any of this is the reason why this problem appeared, only thing I know is those were recent changes. I am therefore putting it up in case it could help see the issue faster. Also, my apologies for not being a better programmer, even though I am working on my C skills at the moment.

#146

I haven’t seen it, but I don’t think I’ve ever used the btrig feature. Already saw some weirdness in op_mul - fixed a weird hysteresis bug in that operator.

On first inspection, line 71 of op_mul should be changed from:

net_activate(mul, 0, (float) v);

to:

net_activate(mul, 0, mul->val);

Compare with the equivalent function op_add_in_b for add operator!

#147

heh, bug is in 3efe2410, fixed in 23baad19, upstream is correct :slight_smile:

yeah, those changes are/could be problematic.

  • be aware signature of net_activate has changed radically in aleph-skektek vs. upstream; careful where the pointers go
  • ops can use float internally if they really need to (there’s no FPU so float math is slow), but don’t pass floats around in the network
1 Like
#148

That fixed it, thanks! I am rebuilding an old sequencer I had made based on STEP, and developing it with some of the new functionalities, which I’ll gladly share once it is working and we have a proper build out for BEES. In the meantime, using MEM1D and MEM2D I noticed that they take up a huge amount of resources (actually about the same for both)… mostly, I suppose, because they can take up to 32768 values for MEM1D and 32768*32768 values for MEM2D. Is that necessary, and if we used 64 values for MEM1D for instance (to address the ARC’s leds for instance), would that make the object significantly lighter?

#149

I’m working on a utility app, called ‘BLOCK’, this one is simply for recording of cv signals, nothing more.

this is the first version, I’m trying to get a stable 48k sample rate, which does not seem to be a piece of cake, but I’m most welcome for any suggestions :slight_smile: this version is polling the ad7329 from the main loop, as I understand there is no internal clock in this chip. first I tried using timers but I could not get them to fire fast enough… I’m measuring the sample rate by sending a pulse at half the frequency to the bfin, and maybe there are potential glitches in this transfer as well… maybe I should call module_process_frame directly in the command?!?

3 Likes
#150

cool experiment, sounds tricky! :smiley:

to clarify a little, i think the (basic) intentions are:

  • read CV (10volt) input on the avr32 at audio rate.
  • send this captured data to the blackfin and simply send it to one of the audio outputs.

so you are basically using the aleph as a level converter. this is, of course, completely ridiculous! you can do the same thing with two resistors. :slight_smile: but if the experiment works it could be used for other things.

here are some issues that stand out to me:

  • doing the capture timing using a busy-loop in main, is problematic. you will have to actually check the elapsed CPU ticks instead of just guessing, because any operations you perform after the timing check will affect the timing on the next iteration.

  • so, i think in general, you would really want to use a timer for accurate timing of events on the avr32:

    • disable all interrupts you’re not using, don’t set up PDCA and USB, &c.
    • forget the whole soft timer system and just use a TC interrupt going as fast as possible. (maybe you can get 48k, maybe “only” 24k, i dunno.)
    • do nothing in the TC interrupt except raise a flag for main().
    • when you see the flag in main, immediately push the last captured value out to bfin, and then start a new ADC capture.

however! you still have a problem: your new hi-res avr32 timer is not really in sync with the audio clock on blackfin. therefore, my real solution would be totally different:

  • the audio clock on the blackfin is actually generated by the audio codec; in the aleph universe it is the immutable law and the last word on timing. process_frame() on blackfin is called from this clock.

  • therefore, initiate the capture event from the blackfin. this is exactly why we have some extra GPIO lines between the avr32 and bfin - namely BFIN_REQUEST_PIN which i think is currently left availble for just this kind of thing. (in the past we experimented by having a “pull” structure for param changes using this pin, rather than a “push” structure, and assumed there might be applications like this where it would make more sense.)

  • set a GPIO interrupt on the avr32 for BFIN_REQUEST_PIN.

  • in that interrupt, raise a flag in main(), process the flag as described above.

  • on bfin, toggle BFIN_REQUEST_PIN every audio frame. high one frame, low the next frame

  • this should give you a 24k capture clock that is always synchronized to the audio frame clock. 24k is not what you asked for but i think it would be sufficient for most purposes relating to capturing CV…

handling SPI from the blackfin is a whole other issue. but with this scheme you should get an SPI interrupt on bfin pretty much right away after raising the capture request. if your process_frame isn’t too heavy you should be able to store the captured value in the SPI interrupt, return and complete process_frame() before the next frame clock.

you could also experiment with the block-processing blackfin branches…

2 Likes
#151

the second (basic) intention you list, I would like to clarify slightly, the purpose is to record and save cv signals as raw sound files, the bfin part was my attempt to measure the sample rate in the main loop.

anyway, your input was really valuable for me :slight_smile: it have gotten me somewhat intrigued by using the bfin as clock now, so yes I’m giving up the main loop timing, after I did some test recordings of an envelope generator and looking at them in protools, they were far from smooth.

a side note, while recording I noticed a weird thing about the cv input values, it looks like 12bit max is reached at a 5V signal, maybe I’m doing something wrong here…

edit: after looking at some more waveform recordings, 0-2.5v reads as a positive signal, 2.5-5V reads as a negative signal, this is after conversion to s16le, so that does seem logical, max registered input is still at 5V.

another thought, since the bfin will only send a timing flag I think this would be an appropriate time to to try it’s 96k clocking capabilities, the cv read is very fast and the spi too, 48k here we go!

#152

gotcha

re: 96k
well, the codec is producing the master clock (AD1939.)

and the bad news is that in the end, we put the codec in “standalone” mode by tying its SPI control pins to ground / 3.3v. (see p.14 of the datasheet)

so, well, you can’t set it to higher SR operation without a hardware modification, followed by figuring out the appropriate control register settings. it’s feasible but, i’d say, not really advisable. (sorry about this - i know there are some misleading specifications out there from before the PCB was finalized.)

however, you could still get 48k capture; instead of toggling BFIN_REQUEST each frame, set it high and then figure out some way of bringing it low after a little time. i’d probably set a 1-shot timer for this but it could just be a busy-wait if you have the time to spare.

#153

aha, thanks, that probably saved me a one day of headaches :slight_smile: will start digging at the BFIN_REQUEST now.

edit: this was way too long with code, better suited for a thread on github…

#154

Once recorded as sound how are you using them? What are the storage limits?

This could be really cool to have

#155

storage is 4 seconds at the moment, I haven’t tried to test if more is possible but the limit will be 512k minus the app.

I think the best use would be to record envelopes or maybe short melodics, only positive voltages can be captured, I plan to use this in tandem with software dev and for that will be a pretty nice thing to have!

#156

Ok cool

curious to see how you use it

#157

the app BLOCK is ready. thanks @zebra for all your great help! I have updated the github link above with the latest build. just to recap, this app records cv signals at 12 bit | 48k and saves them to a raw pcm file format, there is a info file in the link on how to use it, enjoy! :dolphin:

4 Likes
#158

just finished first cv recordings with BLOCK, and I can’t help but wondering if there is a possibility to reconfigure the input range. the optimal would be to be able to use the whole 12 bit range on positive values to the 0-5V, envelopes are usually in the former range so that would definitely work.

I’m happy getting this far but I guess I just need to ask the questions before I can put this to rest :slight_smile:

edited several times: some more tests later and several moments of ignorance (maybe still so) it looks like values over 127 will be interpreted as negative during the conversion to .wav, so the captured input will now simply be shifted down from 0-4096 to 0-127 range, maybe the proper way would have been be to convert to floating point, or shift up to fract32… anyway, this is the final edit of this post now.

#159

How does the aleph act when connected to a computer via usb? Does it turn into a super powered audio interface? Can you direct things from audio outputs to the cv and 1/4 ins and outs? Can audio input go to the computer via USB or cv or audio in? I can imagine this being an es-8 strapped into a pedalboard…

#160

sorry but no, its not a class-compliant USB audio interface. it is a USB serial device.

by and large it is up to the user to design and implement serial I/O applications.

i often use the aleph as a controller via the SERIAL bees op, reporting encoder, key and footswitch values. you could use the same method to report captured 10v values, but not at audio rates.

the other use case in the wild is for general remote control of bees functions from the host machine. (see skektek’s branch, which we’re in the process of upstreaming.) this includes producing 10v values or arbitrarily controlling DSP that does so.

1 Like
#161

sorry, i’m not sure what is going on for you with the input range… i checked and it is working OK for me; the driver produces values in [0, 0xfff] corresponding to [0v, 10v] input. these are just written to a S16 for passage through the event loop and into Bees.

i seem to vaguely remember there might have been a hardware issue around this, wrong reference V or something?

does bees ADC op work for you to capture the full [0, 10v]?