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

Thank you so much for your reply Ezra,

The pan L/R + on/off you are mentioning would work for sure (although I simply thought of having a value from 0.0 to 1.0 for each osc_dac). Then again, about the output mixing in Waves I’d rather not remove the waveshape modulation… Although it can sound like a less powerful version of the phase modulation I really like its timbre as well, and the combination of both is nasty. Now maybe we could give it a try anyway? Or else remove modDel0 and ModDel1 (which I got to like a lot as well now)? Annoying, as I use all of the inputs now, and will have a hard time giving up on any. Still, I would love to try a version with it until you get some time to get into the reprogramming of the whole thing…

Now about the varibright part it would be nice of course (if you can get one yourself someday), and I can see it will take some time but then the main thing to do first would then be to correct the Mono function of the GRID operator: it is still very much possible to have several buttons lit at the same time! I mean, the grid part is very unexploited as it is right now unless we use MP, STEP or WW: the GRID operator is only working one way (meaning the grid doesn’t reflect what is done in the Aleph, for instance - I know, it’s more complex than it seems but we should be able to send back to the grid one way or another without creating a loop), and as mentioned above the MONO function is unefficient. Could of course be great to develop it some more in the future, and there are plenty of things to think of but at least that would make the experience more enjoyable. Personally I know that scene compatibility will have to be broken each time there will be major improvements of the Aleph. That’s life, and I have all my patches on paper for precisely that reason. Hope it’s the same for most of us!

Finally and by the way, I made my own Line function within Bees, which takes quite a few operators (at least 10) unfortunately. It is great, but of course including it as a real Operator would be awesome. Just saying, of course you are already doing all you can and I am incredibly grateful for that!

Thank you again Ezra, all the best!

#28

Hi again Ezra,

I’d like to try some modifications of operators again, but it would be awesome to do that based on v0.7, so I don’t have to add a million small elements each time just to get what I already have from the release candidate. I think it’s a really good version, this 0.7, and so far I only have had good times with it: less bugs, more functions and a lot of fun!

So hope you can release it for good soon, the buggy MONO input of the GRID operator is of course annoying still but apart from that I am very positive, really. All the best, and thanks a lot!

(EDIT - I am actually testing a modified WW tomorrow, with the help of Brian - simply adding a POS output to it, which I believe will be just great. So maybe we should wait one or two days more before the release… If it works as it should I’ll send you a message and the OP tomorrow night).

#29

i’m sorry, i’ve just still been way too busy to do anything with aleph releases. all my equipment is packed including aleph hardware, and to cap it off my laptop OS had a conniption last week and i haven’t been able to take resuscitative action.

anyways the ‘dev’ branch on github is what you want to be using for the latest changes. i really recommend creating a github account and making pull requests for the purpose of getting your changes back into the main repo.

but i think it is also important for multiple parties to test the dev branch with their own hardware and patcvhes before we merge it into main and post a new official release.

#30

Hi Ezra, I could guess you were busy, no problem! And yes, I agree we should make sure people agree with the changes, so let’s wait a bit. Thanks a lot, and good luck with your computer!

#31

By the way, one detail more - and I’ll make my Github account next, it’s a promise: the X/Y position of Bignums is forgotten each time you load a scene. Otherwise I still haven’t found any major issue with the coming release :smile: