#7

thanks for the links I’m in the middle of the tutorials and they’re quite helpful in getting a clearer understanding of the aleph’s capabilities.
i was trying to find out if there is an ‘easier’ way to understand the code that makes up the OP but i guess there is not, which puts modifying an OP beyond my capabilities at the moment. i think having the aleph send out cc values to other pedals or gear would be an interesting addition and would open up a range of possibilities (at least in my head)

#8

indeed, I agree with you.

#9

one reason i didn’t support more midi output types is that i was getting weird artifacts testing the note output operator. like stuck and doubled notes. but nobody else has reported problems, for example brian said it seemed to be working fine for him. i don’t actually have a lot of MIDI gear to test with so it might just be the fault of my setup.

anyways, i would love to hear from other people who have tried using the note output. if there is trouble then i need to debug the midi driver itself.

#10

I know for sure that the MIDICC IN object loses its MIDI channel each time a scene is loaded, which is very frustrating and, although it can be fixed using two presets, requires quite some patience (same issue somehow as with many other objects: BIGNUM, SCREEN etc). Then I’ll try the note output and will report. Thanks!

#11

oh… that does sound irritating. the three ops you mention are ones that i’ve literally never used myself. there is probably an issue with order of initialization. should not be too hard to fix.

if you have a list of init problems you’ve noticed, maybe send them to me at emb@catfact.net

you could also send me a .zip of your aleph/apps/bees/ directory if you want me to add your new ops.

i can put together a release this weekend and try to address those issues.

#12

Edit: it is now DONE, thanks!

#13

@Yann_Coppier
i was able to do a little work over the weekend and have just pushed a couple of updates to the dev branch.

bumped bees version twice, to 0.6.3 with some fixes to graphic ops init/deinit, and then to 0.7.0 with MIDI input fixes that unfortunately needs to break existing scenes that use MIDI input ops.

also added BARS8 and ROUTE16, and did some bees UI tweaking. in particular you can now delete characters in scene/preset names by holding ALT while scrolling the cursor.

and finally, i did add an operator for MIDI CC output. the reason i haven’t posted a new release yet is that this still has some issues that (as i feared) arise from the MIDI driver.

for me, it pretty much works but drops output frames when TX requests overlap. so it still needs a queuing mechanism or similar - the exact solution needs a little thought to avoid a messed up interrupt-timing situation.

anyways i will keep looking at that and probably push more updates soon, but in the meantime it would be awesome if anyone with some MIDI devices and a bees build environment, could help me test the latest changes.

2 Likes
#14

I’ll do it gladly Ezra. This sounds just awesome, just send me the new version and I’ll give you feedback within two days max.

#15

ah ok. if you have a build environment set up i would just pull the dev branch and build it. that way you know you are looking at the latest changes amid potentially frequent update.

but anyways, here’s a ‘release candidate’ build of the current dev branch (last commit #6f81168)

bees-0.7.0-RC.zip (304.5 KB)

1 Like
#16

Of course, sorry I didn’t read properly. I can build Bees myself, for sure. I’m still not used to GitHub, but I am getting better at it and this at least I am used to now. So no need for other release candidate builds!

#17

never complained but it was a nuisance

thanks man!

#18

salivating right now…when this gets sorted i’ll be bringing out a lot of midi boxes gathering dust in storage to test the release

1 Like
#19

looking forward to testing this as well!

#20

hmmm well, I wanted to test this now but my whole Input DSP section is now gone… Meaning in Waves, for instance, no access to Hz0 or Wave1, Cut0 etc. I tried the other modules, restarted on default setup, reinstalled previous versions of Bees but it never came back which is pretty scary. Any idea, someone?

#21

I got it back… apparently my sd card had gone corrupt or something. I am back!

1 Like
#22

ok so first MOUT_CC test hasn’t given me a single problem so far! I had a lot of fun, using a KOMA Kommander to send cv, then transfer it to MIDI and send it to an Eventide H9 to control a parameter at the same time as my 4 knobs controlled other ones. On the other side, and as a detail I ran into some issues while renaming a scene and using Alt: all empty spaces got filled with “a”, and it became a mess rather quickly. Still, this is awesome. I will try and make more complex setups in order to see if I bump into some limitations.

1 Like
#23

yeah the problem i’ve seen with midi out is just very sporadic dropped TX frames with dense output. not something you’d typically notice unless you were pretty carefully examining the stream at the other end.

as for the ALT behavior, maybe i should exxplain it better… (off topic but oh well)

pressing ALT in scene name will immediately instert a null under the cursor, making it the end of the string. scrubbing the cursor while holding ALT will add more nulls, until there is one character left, which then becomes ‘_’

scrubbing the cursor past the end of the string, without ALT, will add characters to the end of the string. previously, the default character was ‘_’ but i made it take on the value of the previous character instead. so if you have jsut “a” and then you scrub right you will end up with “aaaaaaaaa” . but if you carefully move fro one character to the next i think it’s easier to pick new characters by starting from the previous position, rather than always from the top of the character list.

whatever, i’m happy to change the behavior to anything that seems halfway reasonable, or accept anyone else’s changes likewise. the string-editing functions are now a luittle more modularized (in pages.h / pages.c)

1 Like
#24

It all works fine to me now. Should you make it a release then? Or should we add a few more things?
I have a suggestion actually: in the Input page for Waves, from adc0_dac0 to osc1_dac3, the possibilities are only 0 or 1. That prevents very much from panning smoothly, for instance (unless I use my two oscillators as one, use them only left or right, and then play with amp values). It is not the case in Lines, so could we use that code and paste it inside Waves, also for the oscillators? It would really be great, and would allow a lot more than square panning!

Anyway, thanks again Ezra!

1 Like
#25

Ah also, could it be possible to include the varibright function of the 128 inside the GRID operator?

#26

hello hello

sorry for my silence, it has been an exceptionally busy couple of weeks for me between working crunch, and moving house.

re: v0.7 release
i haven’t been able to sufficiently test the bees dev branch to what i think are appropriate standards for a release. at a minimum this means making sure all the bundled scenes work as expected… i’d deeply appreciate if someone would do this; but i guess in this case i’d also be pretty confident just putting up a build. so i’ll go ahead and do that tonight.

re: output mixing in WAVES
i did have the full mix matrix in waves at one point. but it had to go to free cycles for other features. knowing how to code it is not the issue; the issue is that there is no computational headroom left at all.
the whole low-level blackfin framework, and DSP classes, are in serious need of an efficiency overhaul. it’s something i’ve been wanting to do for months and months, and when i’m done moving i should actually have some time to attempt this and other relatively ambitious outstanding aleph dev goals.

perhaps in the meantime we can roll a simpler oscillator module. instead of a full mix matrix maybe it would be useful for each oscillator to have pan L/R and an on/off input to be patched to outputs [1,2] and/or [3,4] (hope that makes sense), and lose something like shape modulation.

re: varibright
the monome driver on the aleph (for which, i suppose, i am basically responsible) doesn’t support varibright commands. the device detection routines do know whether a vari-supported device is plugged in but the actual commands are TODO. it’s not difficult; the reason i didn’t add this is that i don’t have a varibright device myself:
[ https://github.com/tehn/aleph/blob/dev/avr32_lib/src/monome.c#L121 ]

then of course we would have to add inputs to GRID op, breaking, scene compatiblity, or make a VGRID op or whatever.

3 Likes