Qu-Bit Nebulae v2 - alternative software

[thetechnobear]

This thread is for discussing alternative instruments and firmwares for QuBit Nebulae v2.


discussion about the factory firmware and instruments should remain on the main Nebulae topic., questions/discussions on the following software should be on this topic.

I'll try to keep this top post for a summary, more details of piece of software can be in posts within the topic.

If you have any additional suggestions for this list, please post to this topic, and I'll add to this summary.


if you wish to revert, an alternative firmware, you can use :
latest QuBit Nebulae v2 firmware (2.1.2)
-------------------------------------------------------------------------


TheTechnobear
Alternative Firmware : https://patchstorage.com/nebulae-firmware-technobear/
Orac : https://patchstorage.com/orac-2-0-for-qubit-nebulae/
GrainLooper: https://patchstorage.com/grain-looper-modified/
SliceLooper:https://patchstorage.com/slice-looper/
Clds: https://patchstorage.com/clds-2/


Danishchairs
Alternative Firmware : https://neb2.sndwave.com/index.php/firmware

[thetechnobear]

Alternative Firmware : https://patchstorage.com/nebulae-firmware-technobear/
(I believe if you register with patchstorage.com, you can get notifications about updates, by following the Nebulae category)


version 2.2.2


with this firmware my aim was to make it a little easier to organise and manage the Nebulae.

whilst the sync of patches and audio via the usb stick is great, i find it got confusing to know what was on the nebulae, and also found having to copy things to the usb stick then to the nebulae a bit of a pain - so for a while I've stopped this, and instead been using wifi to manage patches and audio on the nebulae directly without the usb stick.
I wanted to make this available to everyone, but in an easy to use form.

this firmware allows you to create an wifi access point what then has a web based file manager on it.
this is simply accessed by holding the speed encoder down during booting process.

note: wifi might cause slight performance issues if engaged, so its recommend you only activate when you need it.


firmware features:
– Enable WiFi Access Point
– Enable Wifi connection to network
– Enable Web File manager
- package installation from usb drive.
- (advanced) wifi mode, also enables HDMI output
- SuperCollider support w/ sc3 plugins

installation:
- copy neb_update.zip file to usb drive
- reboot nebulae
- nebulae will install, rebooting TWICE.
- wait for normal ‘blue lights’

note: should you wish to 'revert' , you can simply install the factory neb_update.zip.


-------------

using access point:

whilst nebulae powers on hole down the SPEED encoder
you will see purple lights as it starts
wait around 10 seconds

on your computer you will see a new wifi network called
Nebulae
join it, password is
eurorack

web access is:
http://192.168.12.1

for connection to an existing wifi lan

advanced use

create a file on usb drive called
wlan0-wifi

(no filename extension!!! )

with the following contents:
(adding your wifi name and password)

Description=’wifi for netctl’
Interface=wlan0
Connection=wireless
Security=wpa
ESSID=YourWifiNetworkName
IP=dhcp
Key=YourWifiPassword

again, reboot holding SPEED encoder and it will use this network instead of access point

IP address will dependent upon your wifi network, you may need to search to find it

note: to revert to access point just remove wlan0-wifi from your usb stick

advanced users... this above wlan0-wifi text file is a standard netctl config, so you can adapt if if your network requires this.
(e.g. static ip, or different security)


Web File Manager

Screenshot 2020-01-26 at 16.29.06.png (74.92 KiB) Viewed 2712 times

Change Log
2.2.2 – add sc3 plugins for supercollider, add default server options
2.2.1 – rewritten supercollider support to use sclang
– fixed pd/sc issue not updating values
2.2.0 – add support for supercollider (credit: Stefano Catena )
2.1.5 – improved web browser, usb loads pdexternals, quick start handling
2.1.4 – improved v/oct handling
2.1.3 – initial release

Credits:
thanks to Critter & Guitari for making their software open source, which web file manager used the organelle one as the starting point, as well as being the inspiration for something similar for the Nebulae
thanks to Stefano Catena for contributing the original SuperCollider support to Qubit, and so into my firmware.

[thetechnobear]

Orac: https://patchstorage.com/orac-2-0-for-qubit-nebulae/

modular with a module - various synths, fx


Note: with my firmware update, it is no longer necessary to use the wifi or pkg installers as these are built into the firmware




new instructions for install orac with my firmware.

- download zip file from patchstorage
- unzip contents on your computer
- copy mec.instr, orac.pd and the two packages files (in pkgs directory) onto usb drive
- place usb drive into nebulae, and reboot it (power cycle it)

this will install....

to use remote orac clients, is now super simple

- download onto your computer.
- start nebulae up as access point (see above post), so now it wifi connect at 192.168.12.1
- start mec, and orac as per video above
- run main.pd in pure data
- at the bottom of patch change address from organelle, to 192.168.12.1
- click on bang button above it to connect.

remember, you can use orac without the remote client, this is only used to 'edit' the presets.

[thetechnobear]

fixed typo.. nebulae address is 192.168.12.1 , also updated orac install instructions for new firmware

[thetechnobear]

GrainLooper: https://raw.githubusercontent.com/TheTe ... oper.instr

a small variation on the factory granular looper, where Ive changed size to a 'fixed' size grain, so that if you move start it does not alter grain size (unless exceeds loop length)
so, the size knob represents the size relative to the total length of the loop, as opposed to the relative to the **remaining** length of the loop (i.e. end-start)

[thetechnobear]

Alternative Firmware : https://patchstorage.com/nebulae-firmware-technobear/
Version 2.1.4

Changes:
- v/oct input is now smoothed much less, so there is no longer a gliding effect when frequent or large v/oct changes are made.
- configurable filter coefficients for cv via nebulae.opt file

to make this configurable, Ive created a new optional support for a new options file nebulae.opt
if this is preset in the root directory of the nebulae sdcard (use web interface to place it there )

its contents can look like

[filterCoeff]
analog = 0.33
hybrid = 0.43
pitch = 0.33
start = 0.43

notes on defaults:
factory : pitch = 0.33, start= 0.43
v2.1.5_tb : pitch = 0.95, start= 0.95

(coefficient 0.1 - 1, 1 = less smoothing)

EDIT: updated for 2.1.5

[thetechnobear]

Clds: https://patchstorage.com/clds-2/

An effect based on the Mutable Instruments Clouds module.

This uses code kindly open sourced by Mutable Instruments, but in no way is supported/endorsed by them.

https://mutable-instruments.net

Installation:
- use my firmware to gain access to the web interface over wifi
- unzip this file on your desktop
- upload the contents to the pd folder on nebulae
(you may need to create it?)
- see manual for how to launch pd patches

note: you may rename the patch to help local it better.

Controls:
Speed = mode (full CCW = granular)
Pitch = pitch
Start = start
Size = size of grains
Density = density (12 o'clock = trig)
Overlap = Texture
Blend = mix blend

Alt_Density = Reverb
Alt_Overlap = Feedback
Alt_Size = Spread

Freeze = freeze

Reset = TRIG


see Mutable manual for more details


Change Log:
1.0 initial release

[drikbreit]

Hi Technobear,
First, thank you for your work on all fronts, pretty amazing :-)

What do you consider the best device for your work on eurorack ? The Nebulae or Terminal Tedium ?

Regards

[thetechnobear]

Hi Technobear,
First, thank you for your work on all fronts, pretty amazing :-)

What do you consider the best device for your work on eurorack ? The Nebulae or Terminal Tedium ?

Regards

thanks

probably best discussed on main nebulae or TT thread.... really it depends,
Terminal Tedium is DIY, but for orac is probably better if you have the OLEDs
Nebulae2 easy to buy, and Im probably doing granular stuff mainly on it.
ideally, Id like to make them both as good as possible, and have plenty of ideas for both - time permitting

[thetechnobear]

busy morning.....


Grain looper is now on patchstorage

Firmware 2.1.5 update...
- improved the file browser, made it a bit more 'user friendly' , and can now access the usb drive
- Ive made it so 'START' is now less filtered, so that you can quickly an accurately move around the loop
- auto install pure data externals for usb drive


Slice Looper released
this is a modified granular looper more suited for slicing, a little bit inspired by how the octatrack deals with slicing

Size = number of slices in loop (1,8,16,24,32,40,48,56,64)
Start = Slice number

Start is now treated as v/oct (0..5v) , such that 1 semi = 1 slice - the idea is this makes it easier to sequence slices !
note: I recommend using my latest firmware to get the improved start behaviour

[yrn1]

- auto install pure data externals for usb

How does this work? Do they need to be in some directory or naming convention?

Does it also work for PD abstractions?

[thetechnobear]

How does this work? Do they need to be in some directory or naming convention?
Does it also work for PD abstractions?

so the current nebulae stuff for pure data is pretty simplistic, it looks for any .pd file and puts it in ~/pd, so ive extended this, so that if it finds any .pd_linux (external) it also puts it in that same folder.
honestly I don't like this approach much, as it implies all pure data patches are one pd file (as abstractions are shown as separate patches !)

the way Ive got around this with Orac (which has loads of externals and pd abstractions ) , was to write a debian package for it (these are 'auto installed' by my firmware ) - this has one orac.pd file which goes in ~/pd, and also has a sub directory for everything else.

so this is just small extension, that makes things a bit easier 'for now'...

--------------------------------------

for the future , Ive got other 'more extensive ideas'
a) instrument directory
each instrument will be a have its own directory , which can have contain whatever it likes/needs,
nebulae will then look for main.pd, main.instr and use that as the bootstrap to start it up .

b) instrument selection
Im also not happy with the way the current patch selection is done, I think it's very difficult to remember what patches are in which slots.
Ive got an idea where will make it much easier to remember what patches you have on your nebulae, and be able to select them

these two new features will work in parallel to existing mechanisms, to provide backwards compatibility.

[yrn1]

Having a folder per instrument would be brilliant for pd abstractions. I now just live with it that my abstractions are seen as patches. Clutters things up though...

[Fedor]

@technobear Can't thank you enough, brilliant work on the firmware and alternative instruments!

I have a couple questions:

1. It seems that in your slicer the secondary functions behave the same way as in the default granular looper. Does this mean that recording incoming audio would fill selected slice only, or the whole buffer? Can't understand this from my testing, but either way this is a very interesting and playable instrument.

2. The way clds instrument react to my pitch knob is strange - it kinda jumps all over the place - not in octaves, but in big intervals. For example, I can't set it to one semitone above default - it jumps up or down considerably from the slightest twist of the pitch knob. Can I somehow help fixing that?

[aphex2000]

Thanks for getting things moving on the Neb! The platform is still so underused unfortunately

Question before i dig into the source code myself:
Is there a technical reason for the 75mb total sample size limit? If not, can it be removed on custom firmware?
I'd really love to put several Morphagene reels on it (the shame!) which are 50mb+ each.

As of now, the USB loader just stops importing after hitting the limit... Or could it be ignored by using technobear's wifi 'sideloading' ?
EDIT: just tested the sideloading and it does not recognize anything past the limit as via USB stick

[thetechnobear]

1. It seems that in your slicer the secondary functions behave the same way as in the default granular looper. Does this mean that recording incoming audio would fill selected slice only, or the whole buffer? Can't understand this from my testing, but either way this is a very interesting and playable instrument.

Ive only changed the behaviour of playback
I dont think it makes sense to change recording functionality, since its likely you want to make a longer recording and then slice it.

2. The way clds instrument react to my pitch knob is strange - it kinda jumps all over the place - not in octaves, but in big intervals. For example, I can't set it to one semitone above default - it jumps up or down considerably from the slightest twist of the pitch knob. Can I somehow help fixing that?

k, so in PD, all I get is a value 0..1 , which I assume is 0..5 , docs says it is 'centred' around 0.6 , so I have made this equal no pitch shift.
I then scale the remaining values according to what clds~ needs which is +/-64 semitone
Im pretty sure this handling is correct - but we know from the granular looper that the nebulae has some 'extra handling' for pitch,
so i'm wondering if something 'odd' is going on with the PD handling of pitch.
(the PD implementation is not really complete, or as well done as the csound implementation - so possible improvements there!)

its a bit tricky to test with pd/nebulae as you can see the patch, but perhaps I'll see if I can install vnc on the nebulae and so be able to edit/see what the patch is actually receiving.

Question before i dig into the source code myself:
Is there a technical reason for the 75mb total sample size limit? If not, can it be removed on custom firmware?
I'd really love to put several Morphagene reels on it (the shame!) which are 50mb+ each.

thanks for this question... as it made me delved into an area Ive been meaning to take a look at

( I knew the code that was processing file handling, but the code which actually loads the file was pretty elusive )

k, so the simple answer is, when launching csound all the files are loaded into RAM, so there has to be some 'limit'.
it appears to be loading via GEN01, and I think the 'issue' is, that if it ran out of RAM the instrument would completely fail to load, or cause perforamcen issues - and it doesn't really have a convenient way of checking to see how much ram is available.


I'd **assume** Qubit tested and found 75mb was the max they could load in
its defined in filehandler.py, self.maximum_capacity = 75
so you could try a higher value, its highly unlikely you'll get it very high - without causing performance issues (e.g. paging to disk)


I believe Morphagene is handling this differently.. (but I dont have one, so this is just my understanding)
I think Morphagene is loading a reel into RAM at runtime from the sdcard - and its 'accepted' this cannot be done without potential audio glitches.
so really files in Nebulae are more akin to slices in Morphagene.

is this possible on Nebulae?
generally the answer is yes, BUT
the current method used in csound only allow files to be loaded at instrument init time i.e. when you start the granularlooper.
Im no expert in csound, but I believe we could use ftgen to load files dynamically...the best way, would be to use this to replace the existing loaded files with another 'set' - thereby continuing the current approach... where 'file' = slice , and then the 'audio directory' would be a reel, and you could load a different audio directories.
note: loading a new audio directory/reel - would not be considered 'real time' , and could potentially cause glitches, or pauses in audio

however... I don't think this is a trivial change, and Id need to play with ftgen to see if it would work properly, and any side-effects.


note: this is a bit of a peculiarity of csound, and the way granular looper is written.
if you were writing from scratch, particularly if you wrote a granular looper in Supercollider or Pure Data, it would actually be fairly straightforward to do.(*)


------

(*) this is something Ive been debating in my own head... do I get more familiar with csound, so I can extend the existing looper, or instead use SC/PD which I'm more familiar with, and use this as an 'excuse' to build something different for nebulae.
perhaps something that is inspired by the existing granular looper of Nebulae, but also Morphagene.

[Fedor]

I guess knowing exact RPi model would give some clue on the total amount of ram.

I have Clouds only in Softube Modular and VCV Rack, and in both cases in goes only +/- 24 semitones, not 64.

[thetechnobear]

RPI3 - you can ssh into it and check, just fill audio and then see how much is left.
But I’d assume that what qubit did, given its trivial to do


Clds - that’s not necessarily relevant, as I use the low level code, how the UI scales ( they are emulating front panel) vs internals can be very different.(*)
When I get a chance I’ll double check - but first I’d like to see what values I’m actually being sent into pd by nebulae.
EDIT: ok, just had a quick look at the clds.pd, I simply forgot to divide by 64... I'll change it, test it, then release


(*) bare in mind, I have this clouds code running on multiple platforms , with same transformation - and no one has mentioned it as an issue on other platforms - hence why my immediate suspicions are its part of the nebulae specific code.

[wolowizard]

First post here!
Already try orac on nebulae and this fantastic! But still can't map Nebulae's knobs (like in video manual)
Mapping on midi devices(via usb) works well. What's wrong?

[thetechnobear]

ok, clds is updated with v/oct fix
(odd one, if you look at the screenshot i had on patchstorage it was correct, so i must have somehow upload from clds.pd file !?)

First post here!
Already try orac on nebulae and this fantastic! But still can't map Nebulae's knobs (like in video manual)
Mapping on midi devices(via usb) works well. What's wrong?

welcome, and glad your enjoy orac

have you checked out this video, at 10:55 i walk thru the step of modulation learn


as you can see in the video it works

as its says steps are: (and these have to be followed exactly
a. add modulation module - A CV in, to one of the modulation slots e.g. m1
b. select the page for the knob on nebulae to want to use for modulation (e.g. overlap is used in video)
c. make sure amount > 0 and modulation bus > 0 on that page (when doing multiple knobs, you need a different mod bus for each knob)
d. change to module that you want to modulate param of
e. activate mod learn (checkbox)
f. wiggle orac param you want to learn
g . wiggle nebulae knob, you selected in b
h. turn off mod learn (Important , as otherwise you will end up learning multiple parameters!)

its a bit confusing at first, but once you get used to it , it is pretty quick to do .

ps. look at the tips on that video too, e.g. for unlearning.

[Bbman]

Noob question. I got that the password for the alternate firmware is eurorack, but what is the username?

[Fedor]

I got that the password for the alternate firmware is eurorack

The network's name is just "nebulae".

[aphex2000]

took a dive into orac today - once it's up and running it's once again extending the neb's potential quite a bit so thank you!

one question and one note:
my first trial as a sound source was to turn it into a Braids. i put "NoteCV IN" on a1 and Braids on a2. i do get it to work somehow but cant make it track pitch properly (i'm using a rene sequence going into v/oct and reset cv ins).
could you elaborate on how NoteCV IN is supposed to work? changing the 2 parameters only made it wonkier.

if there was a desktop/web app to program and manage patches remotely this would turn the neb into an absolute powerhouse!

[thetechnobear]

took a dive into orac today - once it's up and running it's once again extending the neb's potential quite a bit so thank you!

one question and one note:
my first trial as a sound source was to turn it into a Braids. i put "NoteCV IN" on a1 and Braids on a2. i do get it to work somehow but cant make it track pitch properly (i'm using a rene sequence going into v/oct and reset cv ins).
could you elaborate on how NoteCV IN is supposed to work? changing the 2 parameters only made it wonkier.

k, I have to admit with Orac and Nebulae, I've tended to use USB midi input for notes/gate so that it can be polyphonic

the defaults for note in should track properly afaik.
so the way it works is... as an output from this module we want notes in semitones (C3=60), and we use

note = pitchcv (0..1) * amt + offset

pitch cv = 0..1, and covers 5v , so with v/oct = 60 semis, so the default amount is correct (60)

pitch cv = 0.6 = 2 blue lights,
lets say we want this as C3 (midi note 60) , so offset is going to be a bit high.
0.6 = 36, so therefore we want the offset to be 60-36 = 24

so id use, amount - 60, offset =24

of course say 2 blue lights = C3 is arbitrary, so you can adjust offset to 'taste' , id just make it a multiple of 12 (aka C)

and of course, oscillator modules in Orac allow you to transpose anyway - so there is adjustment there.


if its not working still with brds, can you try the basicmono module ,
perhaps there is an issue with scaling on brds module, I've a nasty feeling I had to put a 'hack' in place on the organelle due to it using 44k SR, and its possible that Nebulae has picked that up.
I think this is likely your issue, as it would explain why id not noticed it during testing,
its a fairly easy fix if it is the case, just needs the hack removing .. and it'll mean other synth modules are fine

if there was a desktop/web app to program and manage patches remotely this would turn the neb into an absolute powerhouse!

the web filemanager allows you to 'manage patches' remotely - I'm not sure how this could be improved really.
(I would like to add as the ability to 'restart' nebulae process, as it 'caches' patch names currently)

programming patches... this is highly dependent on programming environment.

Csound, theoretically we could add a web editor for the patch, but we'd also need to capture error console and re-direct....
but if I'm honest, csound is currently a 'passing interest' for me, so **currently** I'd not want to invest the time needed for this.

Pure Data, you need a graphical environment - Im pretty sure I can setup VNC to do this, but I'm not sure I'd want to distribute this to 'end users' , as it installs a lot of extra software, and id be concerned with potential performance impacts - but I'm going to do if on my nebulae for dev purposes, so will see how it goes.

Supercollider, this is a distinct possibility, and one I want to look at for next firmware release. supercollider is really suited well to this...
Ive had a lot of fun with things like live coding with my laptop and Bela Salt (eurorack module)… where I run the audio server on the eurorack, and do dev on the laptop - but then the final patch can be moved over to run on the eurorack too.

[erwincoumans]

Thanks a lot for the alternative firmware for Nebulae v2. The new web interface using wifi works great!

Do you know how we can create bare bones C programs for Nebulae? From the Nebulae v2 manual, it should be possible but it is not explained (in manual nor developers guide). I noticed some file in tests/debug/gpio_test.cc and makefile that may be a starting point. I could use your firmware update to login using ssh to that ip address (alarm/alarm). How would we stop the current running patch, to try our custom one written in C, through ssh?

The following files are able to be loaded and executed, but may require separate compilation and/or accessing the
module through SSH.
• Shell scripts (.sh).
• SuperCollider synths (.scd).
• Bare-bones C programs (.c).
• Python scripts (.py).