I made a couple of synths in Pd, and the first thing I noticed, when I plugged a sequencer to the 1v/oct input, is a quick slew applied to the pitch on every note change. The issue is much worse when adjacent notes play on different octaves.
At first I thought I did something wrong, so I tested also “c_synth_voice.instr”, and it shows the same issue.
Of course, I tested the sequencer with other oscillators, and there’s no slew whatsoever… I tested more than one sequencer… same result, any oscillator plays as expected, Nebulae slews every note that’s different from the previous.
The only thing I can think of is that the ADC driven by the 1v/oct input has a huge hysteresis, or I am doing something completely wrong. Firmware is 2.1.1
Sequencers used to test: Arturia Keystep firmw. 1.1.0.28, ALM Pam NW firmw. 206
Just for kicks, in my Pd patches I added a [ftom]->[i]->[mtof] after the pitch to Hz conversion, before going in the Pd oscillator, but the slew is still there.
Can anyone from Qu-Bit support please shed some light? @shensley @andrewikenberry
Hi @Giovanni
This slew is the result of filtering of the controls on the nebulae being read into the RPi
It is software filtering. So it is possible to modify. However, there is currently no way of controlling the amount in pd or the instr files.
It is possible to edit it on the Raspberry Pi itself within the python code running the module.
The filter coefficient is part of the Control.py script’s HybridData class (for pitch CV/encoder combination).
This could be edited by editing the ControlHandler's self.channels array
Taking a quick look at the initalization there, I believe adding the following after the self.channels list is initialized:
self.channels[1].input.filtCoeff = value
would work to change the filtering amount for that control.
It defaults to 0.33. Increasing the value toward 1.0 would reduce filtering (and therefore slew), while increasing susceptibility to noise.
Hope that helps!
1 Like
Hi @shensley
that helps a lot! Thank you so much.
I ended up changing the default value in control.py to 1.0 and I could not hear the (voltage) noise you are mentioning.
Out of curiosity, is the slew applied to smooth out the pitch’s pot reading?
I am assuming that any changes I make to the code on the Nebulae will be wiped out on a next firmware update.
For controlling that amount, or any other of the goodies that can be found in the code, I might try to put together a socket listener, that might receive Pd’s [netsend]
Talking about modifying the code, what will happen if I update Pd from its current 0.48, to 0.52, so that I can use the new [file] object, to read wav files as wavetables in my Pd patch? (Here I am making big assumptions to find gcc & Co. installed)
Glad you were able to edit it to your liking!
The pitch control uses an encoder, so there isn’t any filtering on the knob portion. However, the filtering of the CV was likely as high as it is to make sure that any system noise or unit-to-unit variation couldn’t bump the control out of the “original pitch”, or other octaves when narrowed into those sections (within the default instrument).
If you’re not experiencing any issues like that, then great.
Sounds like a cool idea to send data from pd back to the nebulae service to adjust that coefficient.
You could probably add that to the existing socket used to send data to puredata as a receive port, though I have not tried that myself.
To answer your question about future firmware updates. Yes, these changes would be replaced in the event of a new firmware update.
If you’re interested in hacking further, and don’t want to lose your changes whenever the next update happens, I suggest that you fork the QB_Nebulae_V2 repo.
Once you’ve done so, you can replace the Nebulae’s local version of that with your github repo, and save the changes through version control.
When a firmware update happens you can either jump back to your version easily enough, by doing the same thing again, or rebase/merge the firmware update’s changes into your own local changes.
Re. updating to the latest version of Pure Data: I don’t think that would cause any issues. I’d be curious to know how that goes for you!
If you do want to make sure you can revert back to any system-level hacks you’ve made so far without losing them you can always make a disk image of the raspberry pi before experimenting with such things.
Alternatively, you can always reflash the stock nebulae SD card image on to start fresh.
Hope that helps 
1 Like
Thank you!
In regard to creating a disk image, I found a lot of “noise” online. Most methods use an intermediate .img file, then burn the image on Windows, blah, blah…
The method I will probably use is:
dd if=/dev/sda of=/dev/sdb
where /dev/sda is the mounted SD ,Arch Linux OS original Nebulae, and /dev/sdb is another SD connected through a USB->SD interface on the Nebulae USB port.
I gave it a thought, but I have not had the time to try it out yet.
What is your opinion?
Yeah, its a tough thing to search for haha.
Your plan of attack should work fine. It will be comparatively slow on the Raspberry Pi compared to doing the same thing on a desktop computer.
On a desktop, you can select the disk itself as the if parameter, and a file, (i.e. mybackupimage.img) could be the of parameter.
On a desktop, you can use a tool like etcher that can be used to do the equivalent of what dd does, but I’ve made plenty of images using dd as well. So whatever works best for you!