Qu-Bit Nebulae v2 - alternative software

[thetechnobear]

the manual I think is worded a bit 'optimistically'
the current python program that is used to 'launch' patches only support PD and Csound,
(I could tell you cunning ways to get around this, but really its not worth it, and not what was meant in the manual )

yes, with the wifi you can ssh directly in... I do this all the time.
yes, you can compile on the nebulae, it has gcc already installed, and you can even install other packages if you need.
(assuming you set up a network connection correctly )

as I've mentioned previously, I want to alter the firmware to have the ability to launch/organise patches a little more 'flexibly', when I do this, its possible I'll be able to reorganise things so that launching Supercollider/Pure Data and arbitrary (C/.sh) patches is pretty much the same code.



Bare Bones C coding - so the best way to do this is for us to extend the python 'launcher' to launch other types of 'patches' (e.g via run script) ,
it would then send knob/cv values via CV in the same way its doing with Pure Data.
this means you don't need to handle gpio directly - which you want to avoid, since if you go to the raw level, you need to start thinking about things like calibration - which is already being handled in the python layer.

connecting a display, this should be possible, but you'll have to check boot command line, and also start 'tvservice', then I believe an HDMI monitor will work. but you might find it easier (I do) to use VNC so you can get a remote display.

Note: I need to point out here, I really do want to help everyone get the most out of their Nebulae.
but, like everyone I have limited time, so I'm not really going to be able to help out much on tasks like networking, or setting up development environments - as this can get pretty time consuming. however, the good news is, Nebulae at its heart is a rPI, and there is a ton of documentation on the web on the rPI, most of which is applicable. just bare in mind Nebulae is based off of an arch linux distro.

[MaxMyriad]

New Wifi interface is amazing. Thank you so much! Makes me wonder if I can load a larger library of samples and then just rename files as needed to bring them to the front alphabetically so that they are the 75 MB that get loaded. Haven't confirmed if this works yet.

I couldn't get the alternate c sound instruments (grainlooper and slicelooper) to work but I will try again this evening.

Clouds PD seems to work which is great. I am running into a couple issues with that however - one is the pitch knob scaling as has been mentioned previously (ultra sensitive and unpredictable). The other thing is that there seems to be a quite high digital-ish noise floor for the clouds patch that is just high enough to sort of make it unusable. Has anyone experienced this themselves?

[Fedor]

Pitch issue was fixed, use the latest version.
I have zero noise issues in granular mode, but I had no chance to test the other modes. I think some of them are quite noisy by design, like spectral madness.

[erwincoumans]

the manual I think is worded a bit 'optimistically'
Nebulae at its heart is a rPI, and there is a ton of documentation on the web on the rPI, most of which is applicable. just bare in mind Nebulae is based off of an arch linux distro.

I'd love to see zynaddsubfx and/or PianoTeq for the Nebulae in Eurorack, using the knobs to pick instrument etc.

See also
https://discourse.zynthian.org/t/eurorack-zynthian/3699
and
viewtopic.php?f=16&t=199986&start=50

[aphex2000]

if its not working still with brds, can you try the basicmono module ,

it's really weird - i feed it with 4 voltages from rene and i get an evolving sequence of more than 4 pitches with some of the steps gliding up and with different gate lengths (the output is not continuous but i get separate notes, as with a simple gate-envelope on top).

i have the same issue with the other synth modules, so its not braids

i'll test usb midi in and see if that works fine and will report back.

the web filemanager allows you to 'manage patches' remotely - I'm not sure how this could be improved really.

the filemanager / ssh & pd remote control are functional but what would really bring it to another level (and i'm not saying you should have to do it as it would be quite a bit of work) would be a fully fledged editor that works without the menu-diving of the pd remote (e.g. i can graphically fill slots and assign nebulae knobs) and easily save / rename / export / import the patches created like that.
I don't know PD or TouchOSC enough to assess if thats a fundamental change to the architecture.

[thetechnobear]

if its not working still with brds, can you try the basicmono module ,

it's really weird - i feed it with 4 voltages from rene and i get an evolving sequence of more than 4 pitches with some of the steps gliding up and with different gate lengths (the output is not continuous but i get separate notes, as with a simple gate-envelope on top).

i have the same issue with the other synth modules, so its not braids

i'll test usb midi in and see if that works fine and will report back.

so this is note_in module

Screenshot 2020-02-24 at 13.37.38.png (42.27 KiB) Viewed 854 times

as you can see the digital in (reset) is used to trig the note output.
if will not send a note out without that trig.
so I guess the thing we need to know is... is the reset firing randomly for some reason.
also as for different gate lengths, again that is purely down to d_cvIn4 doing to zero.


one thing I see that might cause an issue,
there is an assumption in the patch, that the pitch will not change between gate on, and gate off.
really what I should do is store the pitch on note_on, so that IF you change the voltage before sending note_off I send the 'correct' note off pitch.
this is an easy fix, which I'll put on next release

Screenshot 2020-02-24 at 13.50.48.png (37.72 KiB) Viewed 854 times

thats said, I think if you use monophonic forms of the brds mono/basic mono, (which you should be using!) I don't think this should be an issue...
(but its something Id need to test.. but not really worth it, as I will be making the above change anyway )


btw: a point of note here... I released Orac for nebulae , a long time ago ...
Whilst, I obviously tested it at that time, I got zero feedback from users or any evidence that anyone used it - so I really did not pursue it.
I didn't use it much either, as I have Orac running on other modules and organelle, so makes sense for me to concentrate on stuff that people are using
upshot, is there may be some 'oddities' that have not been spotted/resolved - most likely in the parts where it interfaces with the Neb hardware, as thats the code that is different from other (more used and so tested) platforms.

[aphex2000]

thanks very much for your digging! please don't take this as any kind of demand to fix it; you're very well in your right to ignore it - it gives me an incentive to learn more about PD / CSound and co. but i rather just mention the issues somewhere in case someone else comes across it.

this thread just made me look into ORAC only now (i don't have an organelle) and rekindled my interest in the Neb at the same time.

[thetechnobear]

so, i had a look at this, and tried the above fix - and posted new release on patchstorage (2.0.1)

now it looks correct, but there are some issues...
a) the modules do look out of tune by a few cents, which i don't really understand why...seems to be a constant amount.
(bare in mind neb is running at 44k, and so is organelle - so there should be no tuning issues)

b) if i set a sequence playing (externally ) into v/oct, reset. sometimes its playing a previous note. this appears to be because of some issues with timing of the trig(reset) and gate - its a bit confusing, i need to really look at the underlying data - as it felt like data is being delayed or something

c) v/oct is floating around - this is something we have seen in the firmware generally, and its a real problem if you are trying to use pitch/gate since its imperative that pitch is correct when the gate is received.

unfortunately, I've also found its a bit of a pain to debug PD on the nebulae , it looks like i cannot install a vncserver without upgrading a lot of the OS, and that has a risk of making it unbootable - not really an issue, but its potentially time consuming - and I really need to move the Neb to my dev rack to do it.

as kind of stated above, im not sure any of the issues above are specific to Orac, rather I suspect they are other general issues in the firmware, or perhaps how it interfaces with PD - but more digging required.

[MaxMyriad]

New clouds pitch knob works great (better than original clouds given the LED indicators, reset, etc)! And for some reason the noise floor issue seems to be gone, so good news all around. I'm guessing the bit depth/quality/buffer time modes aren't broken out to controls on the panel in this port? It's ok if not, just checking.

I was also able to get the grainlooper and slicelooper instruments to work (I think they had a .txt after the .instr and removing the .txt made it work). Slicelooper is super fun I sort of wish the slices were spread evenly along the knob but I totally understand the design decision with v/o selection and it's quite fun to sequence slices with a note sequencer! Thanks again.

[StefanoCatena]

Hey folks!

I made a SuperCollider version of the Nebulae OS: it was a while back though
https://github.com/StefanoCatena/QB_Nebulae_V2/tree/dev

For those who would like to try it, you are welcome: if you find some bugs (which there are of course) it would be cool if you could point them out to me or make changes to the GitHub.
Unfortunately the current OS cannot read .scd files (so no live coding) since it basically works by sending compiled SynthDefs to a server running on the Nebulae. You upload the .scsyndef (just like the standard OS) and select which one to load: on reboot it will remember the last used synth. This clearly has some disadvantages as you cannot make extensive use of the language (it's all server side) and will have to deal with buffers locally in the SynthDef: but you can read the local .wav files on the Nebuale, so you can choose between live input and the sound files.

Stefano

[drikbreit]

Supercollider, cool !
I think @thetechnobear was also going to integrate Supercollider into his firmware.

[thetechnobear]

yeah, my version of the firmware was based off the dev branch of the source code - so does indeed include @StefanoCatena code.
(I did mention this when I released it )

[StefanoCatena]

yeah, my version of the firmware was based off the dev branch of the source code - so does indeed include @StefanoCatena code.
(I did mention this when I released it )

Hey! I downloaded the code from the site in this thread but.. it does not seem to have the code I made in that branch. It's not a problem though, if you want to I can see to update the code from the latest update you made.

Stefano

[thetechnobear]

sorry, Id merged it into my branch (on GitHub), but forgot to upload the new firmware update to patchstorage

https://github.com/TheTechnobear/QB_Neb ... es/v_2_2_0

https://github.com/TheTechnobear/QB_Neb ... technobear

its late now, I'll upload it tomorrow

[StefanoCatena]

Great! I'll update my Nebulae as well!

Thank you,
Stefano

[thetechnobear]

ok, uploaded by firmware that incorporates Supercollider support thanks to Stefano Catena

@StefanoCatena (and others wanting to use SC on Nebulae)
I've not played with this a lot with yet, really just created by own synthdefs, and gone the the process of how you get that to the Nebulae.

whats you thoughts on just having server support compared to also including sclang?

on the Organelle, I got sclang running headless, by rebuilding it (to avoid issues with Qt/X) , and so I could do this for the Nebulae as well,
and its easy enough for my firmware update procedure to then install the new supercollider package.

but Im kind of in two minds....
- advantage of current approach (scsynth only)
its simple, no need to build anything extra - its quite focused.
if you want to do live coding, you run sclang/client on your laptop anyway.

- advantage of sclang approach
it's a bit more 'complete' for patches, as a lot of supercollider is done client side.
the obvious additions are things like midi and osc support, but I also if you want generative stuff you have ndef etc
we are transferring text (sclang) to nebulae, rather than having to build binary stuff to be executed - so its a bit easier.


as I say, I'm in two minds... I think for my purposes, current approach is fine.

[StefanoCatena]

If you could add the sclang support it would be VERY good: you could write scripts for the server instead of single synthdefs. You could instantiate buffers, create more synthdefs running in cascade etc.. The live coding as you mention would need to be done in remote anyway, so it would be something possible regardless. In fact sclang would be a lot better: the possible complexity of the synths would grow a lot, possibly even support Quarks.
It would be a great addition the support for the sc3plugins, which I wasn't able to create (I'm not so good with Arch Linux and SC really wouldn't want to recognize them, no matter where they were). Also now whenever you change synthdef you kill and reboot the server every time, which is something I should actually modify.

Last but not the least: am I the only one with a strange timing error with incoming triggers? ex: I make a synthdef with an envelope which starts when I send a trigger in the Reset in. 85% of the time it works, 15% the trigger is skipped and this destroys the rhythmicality of the patch. I think it also happens in Pure Data mode, but not in Csound mode. What could be the problem? (this is still with my old firmware, I wasn't able to update yet).

Stefano

[thetechnobear]

ok, Ive got a kind of 'beta release' (2.2.1) for sclang....
you can download it here : https://github.com/TheTechnobear/QB_Neb ... update.zip
its beta, in order to get some feedback on the new supercollider support.


so things are now rather different
the old synthdef files are no more
instead we now use .scd files for supercollider and contains sc lang code

so once you have installed it, how do we use it?

lets see and example... create a file called test.scd , and put the following in it.

Code: Select all

~synthdef=SynthDef(\testSynth, {
	arg freq =440;
        var sig;
        sig = Saw.ar(freq);
        Out.ar(0,sig!2);
    }
);
~synth=nil;

OSCdef( \oscPitch, {
    arg msg, time, addr, recvPort;
	~synth.set(\freq, msg[1].linlin(0,1,440,880));
    },
    "/neb/pitch",
    recvPort:3000
);

s.boot;
s.doWhenBooted {
    ~synthdef.add;
    1.wait;
    ~synth=Synth.new(\testSynth);
};

note: this is not optimised, it may be we want to set some server options in the above

you can now upload this either via the web app, or via usb

then invoke it on nebulae, launch the patch browser, and twist twice, so we get the get 2 top light off, and 2 bottom lights green, then launch as per usual.

doesn't do too much ... basically you get a saw wave, who's pitch will change when you change the pitch.
(note: as you can see above, I didn't do v/oct above its just interpreting values in range 440-880hz)

so whats going on?

well, with this code we can also see a radical change.... the cv/knobs etc, are now sent to the sclang interpreter as osc messages, on port 3000
(note: Ive not got support for sending outputs yet)


why send to sclang , rather than directly to the server? thats a good question...
the reason is is slightly more flexible, since it means that sclang can also be used to modify and interpret cv/knob values, rather than assuming they should go to engine. e.g. this would be useful if using things like Pdef
also, having the knobs/cv client side, is a bit more 'common practice' for SC e.g. it works the same was as midi , which is also client side.

what are the osc messages?
they are exactly the same as those listed for pure data, just with the prefix /neb/


anyway, Ive not done much with it yet, rather just testing it out


footnote:
how do you test you patches , say on your desktop first?
actually this is the main advantage of using OSC, none of the code used above is specific to the Nebulae.
so when your developing on your desktop/laptop, you can simply run the code in supercollider and send in osc messages (lots of ways to do that ) to test it


tech notes:
underneath the covers, Ive also rebuilt supercollider, so that sclang can now be used headless on the nebulae,
the nebulae code is much closer to how pure data is implemented... I simply launch sclang as a process, and then send messages to it via osc.
note: there is some redundant code in the GitHub repo from the previous implementation - I'll remove this once its ready for 'release'
(SuperCollider.py libs/scsynth etc are no longer used)





anyway, Id love to get some feedback, if there are no obvious issues then I'll upload it to patchstorage.

[thetechnobear]

ok, Ive released my firmware 2.2.1 to patchstorage

two main changes from 2.2.0
- supercollider support is now re-written to allow use of sclang, which opens up lots of new possibilities
- improved supercollider performance
- fixed an issue with pure data and supercollider not getting up to date values in some scenario

(*) I believe this might fix issue with missing trigs on reset (pd/sc only)

you can find a couple of useful supercollider patches to get you started on my Nebulae Repo:
https://github.com/TheTechnobear/NebulaePatches
(they are in the sub directory sc)

[muffmuffmuff]

@thetechnobear
Thank you so much for your great work!
I have been playing around with your firmware and everything works perfectly. The USB on my Nebulae is not working reliably (sometimes USB drive is recognized, sometimes not) – so the ability to upload files wirelessly without the USB is a big help!

Question 1 / Wish:
Would it be possible to store the "wlan0-wifi" settings on the Nebulae itself instead of the USB? So the decision for "access point mode" vs. "connecting to a wifi mode" would not be dependent on wether there is a USB or not. As mentioned, the USB of my Nebulae is often not recognized (although plugged in), which leads to the Nebulae sometimes creating an access point and sometimes not, which is frustrating.

Question 2:
After uploading audio files or instrument files to the Nebulae via the web interface, is it neccessary to reboot the Nebulae in order to access the new files, or is there another way? I tried pressing File+Source ("Reload files") but that didn't seem to work. (I am aware of the source beeing a falling edge sensitive button issue).

Again, thank you!

[thetechnobear]

Q1.
I'll have a think about it...
access point mode is actually more useful for most people - so that is not going anywhere

the nebulae actually already has your wlan0-wifi setup, so its just a matter of me deciding how to choose between using AP or non-ap mode.

(AP mode also still very useful even if you have wlan0-wifi setup as its a good 'fallback' solution e.g. if the neb has issues connecting to your network)

btw: you can enable wifi permantely if you wish , by logging on an typing
netctl enable wlan0-wifi

netctl disable wlan0-wifi , will stop it.


Q2.
well, yes and no.... the 'reload files' in csound, is not actually that 'comprehensive' e.g. it wouldn't work for pd etc.
what I could probably do is actually add something to the file browser to close all patches, and restart nebulae process (not the same as rebooting, and would be virtually 'instant')

[muffmuffmuff]

Thanks @thetechnobear — looking forward to what you come up with!

[timcross]

Installed the firmware, great work thetechnobear!
So much easier being able to see what's going on, what's installed etc

[pisrecords]

When you activate NebulaE2 WIFI, does this module consume more Amps from the Rack power supply?
muchas gracias for your work ! <3

[Fedor]

When you activate NebulaE2 WIFI, does this module consume more Amps from the Rack power supply?
muchas gracias for your work ! <3

I don't think so.