#38

Raspberry PI3 running arch linux.
its been really well done, boots extremely quickly,
I’m impressed how well its been done.

2 Likes
#39

Ah that’s really cool! So presumably alternate firmware development is just as ‘easy’ as programming on desktop Linux?

#40

@TheTechnobear woooooah. Are you saying that (potentially) we can install ORAC 2.0 on a nebulae v2? that may change some of my plans for my euro if thats the case… :open_mouth:

2 Likes
#41

Unless things have changed dramatically since Version 1, programming on the Nebulae should feel an awful lot like working with a Raspberry Pi. The original Nebulae used stock Raspian. The switch to Arch largely was done because of the faster boot time. It isn’t terribly difficult to get anything running on a Raspberry Pi running on a Nebulae, which is what makes it such a cool device for musical hacking.

1 Like
#42

Yes per @TheTechnobear’s video intro. With remote configuration via OSC control. Amazing stuff…

2 Likes
#43

ok, so I dont really want to cross-post here… as I have an orac thread

so today Orac 2.0 is available for the Nebulae (the post is on the Lines orac thread here)

Im actually pretty happy with it… as its a bit different from other Orac version I think… to me it feels more like Im building my own module, when building an Orac ‘rack’.

Im looking forward to exploring it - bare in mind Ive only had my Nebulae about a week, and given I was releasing Orac, I think Ive spent more time coding for it , that actually using it - thats going to change now I hope.

as @PaulBatchelor said, its not that difficult to get code thats already running on the Nebulae - after all its all a SMOP :wink: but there are some things you have to deal with.

you need to add CV support, without it , its pretty useless … and you also have to deal with the fact it’s ‘headless’ .
so Orac 2.0 has both CV support and a remote interface to deal with these issues.

installation - unfortunately the nebulae only installs simple wav, instr and pd files, no binaries , no libs, no pd externals - so I had to create a way to do this … and do it cleanly !

similarly out of the box, there is no wifi access… needed for remote control, again I created an instrument to do this too .

finally, I found that midi was not enabled on Pure Data (only csound) so had to figure that out too :wink:

so yeah… not hard to port something from a rPI, but it still requires a bit of effort, and careful consideration if you want to make it available to non-techies - which is always my goal on these platforms.

anyway, Im pretty happy with it.

I will say I don’t think Orac will appeal to all Nebulae users, its really flexible, but with flexibility there is an inevitable complexity, and a certain investment of time to understand it.
but Im hoping it still will become a useful for everyone for a couple of reasons

a) sharing presets
because the nebulae is the same for everyone, we can share presets built with Orac, for those that for what ever reason are not ‘into’ Orac.

b) reuse the platform/architecture
so as I mention this video, Orac is really a kind of ‘platform’ , its derived from my MEC project.
what this means is, I can create specific patches (e.g. say a Clouds patch, based on my Mutable port of clouds) , which has many features of Orac… but without any complexity.

anyway, early days… lets see :slight_smile:

on another note , you’ll see Im hosting this on patchstorage.

I got the guys at patchstorage.com to create us a specific ‘Nebulae’ category, which also supports .instr files - so we have somewhere to share out instruments .

(Ive put a couple up there to help seed it … you don’t need for Orac, as they are included, but they are useful anyway)

Enjoy, and happy patching
Mark aka TheTechnobear

10 Likes
#44

@TheTechnobear Once every so often you see a piece of software that disrupts its category. Orac has every opportunity to do that in the modular/electronic instrument space.

I spend a lot of my professional time on the economics of software platforms and I do wonder how your new platform might disrupt the hardware market. We’ve seen this play out before: specialized single function devices give way to generalized software platforms that abstract that underlying hardware. Norns of course is doing the same thing. How are the QBit folks - and other module designers - going respond to this disruption. In the short-term I can see folks wanting to have two Nebulae in their racks, one for its native functions and one for running Orac. In the longer-term it looks like Orac should create a market for general purpose modules that compete on UI and interaction model rather than specific functions. What ever happens the disruption you’ve enabled will likely be the foundation for another round of innovation in the modular and electronic instruments world. Kudos!

1 Like
#45

I’m not sure I get the “disruption” here, nor do I believe the intent of Qu-Bit was ever for the Nebulae to have a “specialized single function.” After all, it does come with multiple firmwares to boot, and users are encouraged to play around with the PD/Csound files. That’s why they upload alt firmwares on their website. Nebulae, both v1 and v2, was created for this purpose and is much much more than just a granular sampler. At its core, the Nebulae is a Raspberry Pi with a panel, knobs, and inputs/outputs that can be turned into whatever the user wants. It seems that Orac is a logical outgrowth of this ethos.

That said, I think that Orac looks cool as an alt firmware, and I’m hoping more info/demos comes out about it soon.

2 Likes
#46

That’s a fair point about the open architecture of the Nebulae though the panel layout and interaction model is clearly optimized for its primary functionality. Orac 2.0 provides a higher level construct for managing interaction between multiple functions on the same module. I do think that is disruptive in the modular context. Unless I missed something Norns lacks that with its single function/script at a time execution model. How interesting would it be to layer Orac on top of Norns to provide modular multi-script patch building and management. Irrespective of disruptive or not it is cool to see this type of innovation in the modular world.

1 Like
#47

Disclaimer: I am not officially affiliated with QuBit, and my thoughts/opinions are my own. However, I did help QuBit out a fair bit when the company first began, and can provide some insights about the development of the first Nebulae.

Some background: I introduced Andrew and Jason to the Raspberry Pi back when it was being developed at Berklee, and also gave them advise for how to get started building the firmware for the Nebulae. I also was the one who got the initial PD support working on the device. (Oh! And that’s me playing the bass and ukulele in the QuBit sample pack.)

So, as for the “intent” of the Nebulae: The original idea behind the Nebulae was to use Csound as a synthesis engine to build a eurorack module. Not a reconfigurable module. Not even a Csound module. Just a module that incidentally used Csound for the DSP. In this case, this module was built around the Mincer and Paritekkel opcodes. I think this design choice reflected CsSpectral, an iPad synthesizer being developed by Richard Boulanger (and us), which used Csound as the underlying synthesis engine. We were very used to the concept of using Csound to build synths.

Shortly after building the initial prototype for the Eurorack, Andrew and Jason published a paper in the Csound Journal on building an FM oscillator using Csound, Pi, and Arduino:

http://www.csounds.com/journal/issue18/eurorack.html

Note how this specifically talks about building an FM oscillator, and not using Csound in general. We were testing Csound on the original Raspberry Pi model B, so there were restrictions on which parts of Csound you could use. Things like sampling and FM synthesis with limited voices were all that you could really do. I actually remember being very impressed that they could get something as complex as partikkel running on that thing. AND Mincer!

I think extendability was always something that was going to be there, but as sort of an afterthought. Sort of a “it’s there, so we might as well” kind of thing. It was full-on Csound. It was running Linux. Why not? The original concept there was to allow people to just load their own Csound patches. PD support only came after people were requesting it. It was never part of the original vision. Luckily, it was just Linux, so most of the groundwork was in place.

Linux, by the way, was definitely a means to an end. It was an easy way to get Csound running on an embedded system. If we had figured out how to get Csound running as some kind of realtime OS, we’d probably would have gone with that. The big picture idea at the time was to get Csound into Eurorack, and that was basically it.

The Nebulae was designed as a phase vocoder + granular synthesis module, kind of like how the TB-303/TR-808 was built to be a band-in-a-box for singer/songwriters. QuBit did a very good thing when they decided to let people reprogram the Nebulae. By making the Nebulae hackable, they gave it permission to grow and evolve beyond the intentions of the original creators. I imagine people will find new uses for it for years to come.

22 Likes
#48

Since you seem to have influenced the use of the Pi, do you know why Qu-Bit decided to use the ‘normal’ form factor rather than the compute module? I can’t help thinking it looks like an odd design choice with the Pi slotted onto the back of the module.

1 Like
#49

It’s likely that the original QuBit Nebulae was in development before the Compute model came out and they stuck with it?

#50

The compute didn’t really exist at that point (we were doing stuff around 2012 right when the Pi first came out). Even if it was available, I don’t think we’d know how to use it. We were music students at music school with no engineering backgrounds, so there was a lot figuring stuff out as we went along. While less elegant, using the Pi board gave us a simple solution which yielded more knowns than unknowns. It got the job done quickly.

QuBit has of course evolved quite a bit as a company, and their manufacturing process has matured since the days of hand-soldering Nebs in a tiny Boston apartment. They of course know about the compute now, and they do have the means to use it, but yeah I think it just made more sense logistically to stick with the original design.

5 Likes
#51

Ah okay. This is all very interesting, thanks for taking the time to answer my questions @PaulBatchelor

1 Like
#52

Hello everybody.

I’ve received my Nebulae V2 two weeks ago and I really enjoy it. I understand how the module works and how I can load new samples but I never found how to use “live source” and the “record mode”…

The button “Source” never hold…
Do you undestand what i’m doing wrong??

Thank you so much.

#53

it needs a tap to switch mode.
this is because if you hold it, it provides access to other (secondary) functions.
(i.e. acts like a kind function button)

(its not particularly sensitive to this, once you’ve done it a couple of times its easy)

#54

Yes, I understand that if I hold “source” button I will enter in secondary mode but when I tap one time the source button the “file” button light one time too and the both turn light off and nothing happen… Nebulae still playing samples loaded into the module…

However, when I tap the record button, he’s keeping hold (light on) and I’ve got the two red lights aroundt the speed encoder but I can’t ear if I record something…

#55

Ok… Sorry everybody… I just find the solution for the “source mode” : push hard this fu##ing button!!!

Mine is maybe strange because I really need to push it hard one time to go one the “source mode”… but its ok, it’s working now and it’s open a crazy world for me!!! :wink:

#56

I got a Nebulae V2 a few weeks ago, and in general I’m loving it. One thing I’ve noticed that is quite quirky is the recording overdub mode. I downloaded the new firmware so it will keep recording over a loop until you turn it off, however when I try to do this I’m hearing all of the these pops and clicks and it appears that the loop length gets altered too. I’m used to good old fashioned guitar loop pedals where you can just overdub to your heart’s content without any clicks or pops and this doesn’t seem to be working this way and its quite frustrating. And no, I’m not in the granular mode.

#57

Hey just following up here…
So I’m still really loving the Nebulae, the one main point of contention is this: I want to be able to mute the live audio input that’s going the output of the Nebulae and still be able to add live audio to the buffer without monitoring the live input to the output. The way I’m mostly using my Nebulae is to pull live audio from various channels of my mixer through an aux send, and there’s enough latency of the audio coming the Nebulae that I’m getting phasing and doubling artifacts when I sample live audio.

I know nothing about cSound or how these alt instruments work, but I do a bunch of front end web coding for my job. Can anyone point me in a direction as to where I should look in the code to try make this change for myself?

Shouldn’t it just be as easy as a mute function for the live audio to output?

edit…

Looking at the Nebulae Code here:

There’s a variable called “ablenddry” which i’m guessing handles the dry sound and then on line 898 and 899, this bit of code exists:

aoutl = amixl + (ainl * ablenddry)
aoutr = amixr + (ainr * ablenddry)

Guessing if I just remove the “ablenddry” this may work to remove dry sound from output, no?

Is it just as simple as making a copy of this instr file with changes and loading onto USB stick onto the Neb?