nw2s::b - Arduino based algorithmic controller

Discussion, support, and resources for our noise making modules and kits.

Moderators: Kent, scottwilson

User avatar
akrylik
Super Deluxe Wiggler
Posts: 1907
Joined: Sat Feb 18, 2012 9:13 am

Post by akrylik » Mon May 19, 2014 2:32 am

Well, I isolated the offset problem to a faulty opamp channel on one of the TL074's. I'll probably replace them all with TL064 since they are 1/7th of the power consumption and for the 12-bit ADC's on the Arduino DUE there is no point in having the lower noise characteristics of the TL074, IMO.

FYI, the nw2s consumes on average about 180-200mA.

Build gotcha:

Try running all of the test sketches BEFORE attaching all the knobs and jack nuts to the front panel. This way if there is a problem you don't have to waste a half hour removing them and putting them back. :doh:

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Mon May 19, 2014 10:32 pm

Sorry about the bad TL074. I haven't come across a bad one yet. Any time I've had trouble biasing, it was either because of a missed solder joint or a bad interconnect.

The missed solder joint, of course is easy to fix. I have a special tool I use to make the cables, but if any one gets a cable with a wire that is not making a good connection, then a small flat screwdriver will be able to push the wire down into the slot a little further to make the contact better.

And here's my test/tuning sequence:

0. Apply power! That's always fun. If you're not 100% sure, you may want to test the resistance at the power connection. Make sure that there is a high enough resistance (more than a few kΩ) between the +12, -12, and GND power inputs.

1. Set noise gain - I set to what my o-scope says is about 18V P-P

2. bTestRNGTuning - There's a little interplay between the noise gain and the RNG tuning, so do this after. You run the sketch, open the terminal window, and tune until you get about 50% ones and zeros.

For those who don't know, the Arduino cannot actually generate random numbers, so I use a noise circuit into one of the spare digital inputs. This signal gets XORed with the pseudo random signal (the reason for that, I'll leave to the student to figure out) in order to generate a truly random (or at least non-deterministic) sequence.

3. bTestAudioOutputs - Spits out a saw wave onto the two DAC outputs. You can set this to what you want... you can go as high as about 16V P-P, just watch for the tips of the triangles to start to round off... or be safe and set it to about 10V P-P.

4. Reset Button - hit it. Make sure it works. Make sure that when the EventManager.init() runs that all of the lights light up. If they don't then you should start debugging before you go any further. Most likely just a cable that needs a little poke with a sharp stick.

5. Pair BT - set up pairing with your computer. There's a whole article on how that works. (http://nw2s.net/bluetooth-pairing/)

6. BT indicator - Make sure the BT indicator lights up when you have the port set to the BT port and the serial monitor open in the IDE.

7. BT reset via DTR - make sure you can reset the device from the BT connection. I use SerialTools on OS X. Toggle the DTR pin from within that program and the device should reboot.

8. bTestSD - This will read the contents of the SD card and spit it out to the serial monitor. This will test that 1. your SD card reader is working, 2. your SD card is readable, and 3. the SD indicator light works.

9. bTestAnalogInputs - This is the easy biasing since the input gains are fixed. Just adjust the input offset bias trimmer until you get as close to 0 as possible. There are lots of numbers in this display. The one you're looking at is the third number of each column. This is the mV value of the input CV.

Make sure none of them are very far off from the others (as in more than about 10mV) The final column is the average of all 12 inputs.

10. test input pots individually - Then go through and turn each pot all the way up and make sure you're getting close to 5000 mV input.

11. test input jacks individually - Then use a really slow bipolar LFO (I use my morphing terrarium) and plug it in to each of the input jacks one at a time. Turn up the input pot and make sure that you're getting positive and negative signals going to the ADC.

12. bTestDigitalInputs - test each toggle, both momentary and latched. Note that the first column is actually the noise signal piped to one of the digital inputs, so you're really interested in the last 8 columns.

13. test input jacks individually - Then plug a clock or gate into a digital input and turn it to the latched side. Your display should show some ones when that gate signal is high.

14. bTestAnalogOutputs - This is the tough biasing.

So here's what you're doing... you're adjusting two settings. One is the gain of the op amp. This is what the 16 trimmers lined up in groups of four do. The second thing you're doing is adjusting the input offset value. That's what the one trimmer off by itself is doing.

Another way to look at this is that the gain is setting the overall _range_ (i.e. 5V p-p or 20V p-p) while the input offset is setting the _midpoint_ of that range. Problem is that the gain affects how much the input offset voltage shifts the midpoint, so tuning gets tricky without an analog computer to help you out. Oh wait. What's this thing I have sitting here?

Here's where I start:

Using a digital multimeter, clamp to the USB plug housing with the ground side. Directly below the offset trimmer there is a via. Poke your positive lead at the via and measure the voltage.

You want to start about 0.837V for a +/- 5V bias and you want to start about 0.909V for +/- 10V biasing.

Once you're there, switch your DMM to something that can measure the output of the 3.5mm plug (or disconnect the ribbon cable and clamp to the pin header, but I prefer to measure off the 3.5mm. otherwise, I'd have to also test the 3.5mm plugs separately.)

When you run the sketch, the first switch toggles between all -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, and 5V. If you're biasing for +/- 10V, it shows those values, but you're really tuning to 2x those values.

Confused yet?

Anyway, set the toggle until the serial monitor shows that the output should be 5V (5000mV).

Your DMM will not read 5V unless you are incredibly lucky. Turn the gain trimmer until the DMM reads 5V (or 10V, remember!).

You have now made a first stab at 1. setting the input offset and 2. setting the gain.

Nothing is that easy, however. We need to make sure that -5V is correct. It probably isn't, so hit the toggle until -5V is being shown in the serial monitor.

What you'll see is that it's probably reading an actual value of -5.5V in the DMM.

What does this mean? This means that you've got about 0.5V too much range (gain) and the midpoint (input offset) is about -0.25V too low.

So shift the input offset by about -0.10V, making the DMM read -5.4V, and then decrease the gain until the DMM reads -5V.

Now lets see where +5V is actually reading... It won't be 5V any more... it'll probably be about 5.1V.

So do the same. Decrease the input offset just a hair, then decrease the gain just a hair. Make it read 5V. Then check -5V and see what it's reading.

You get the picture. Oof. It's a bit of work, but once you get the first one set, you can breeze through the rest without touching the input offset, just set them all to as close to 5V as possible. You can basically get them all to +/- 0.5% with some work.

If you're tuning to +/- 10V, the gains are a little higher and the position of the trimmer makes it such that tiny movements make big changes in the bias points, so it's just possible you'll drive yourself crazy. Fair warning? Okay maybe a little late.

Well, if that hasn't scared everyone away, then great. If it has, well, get it close. I may at some point add in a custom precision mode where you can digitally tune the last few millivolts the way some precision DACs operate.

-s

User avatar
daxton
Learning to Wiggle
Posts: 14
Joined: Mon Apr 25, 2011 11:21 pm
Location: toronto

Post by daxton » Wed May 21, 2014 11:18 pm

Received my built module today - I don't envy you DIY guys, this thing is a beast!

Great fun so far, mostly just fooling around with Alanesque, modified with a few triggers and probability triggers. Looking forward to digging deeper into the code.

If I wanted to do something like use the digital inputs to "mute" various trigger channels should I just call some digitalWrites after EventManager::loop or is there a hook in the API to override device behaviors? I'd also like to be able to halt/pause the clock via a digital input, I guess my best bet is to extend VariableClock?

One minor issue I've noticed - since I don't have Bluetooth on my PC I'm connected via USB. It looks like 5V is leaking back into my Euro power bus (i.e. turn the case off and some modules still have some LEDs lit). Those modules tend to not work when I power the case back on - I need to disconnect the USB before powering up the case. Not sure there's any way around this (I guess just buy a BT adapter!)

Thanks Scott - simply amazing work. I can't wait to see what you and the community come up with!

User avatar
akrylik
Super Deluxe Wiggler
Posts: 1907
Joined: Sat Feb 18, 2012 9:13 am

Post by akrylik » Thu May 22, 2014 1:36 am

Scott, thank you for the write-up on the testing procedures!

You're right there, daxton. The nw2s kit is not for the faint of heart. :woah:

However, if you

- have patience
- have good tools
- enjoy problem-solving
- follow Scott's tutorials to the letter
- spend the time to understand the schematic before building

then it is quite a rewarding build.

Don't have any free-time right now but I think my first sketch will be something along the lines of a utilitarian array of beat-synced LFOs coming out of the analog outs with resets and end-of-cycle outputs.

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Thu May 22, 2014 5:28 am

For adding new behaviors, yes, the best way to do this is to either extend a device or to just modify one if extending it would overcomplicate the class structure. This seems like an example where you'd just want to modify the base class.

To do something like what you describe where you want the clock to not fire any events if one of the digital inputs is 0, then I'd do the following...

Let's assume for the time being that we don't want to _stop_ the clock, we just don't want any events to fire

Let's also assume that we want to change the behavior of all the clocks - since Clock is the base class and provides all of the timing functionality, that's where we'll want to tweak the logic.

First, add a new setter and a private variable to Clock in Clock.h

void setResetDisableInput(PinDigitalIn in);

and

PinDigitalIn resetDisable;

Then initialize resetDisable to DIGITIN_IN_NONE and implement setResetDisableInput in Clock.cpp... I won't do that here.

The next step is to check the digital pin before calling reset() on all of the devices attached to the clock... This will allow the timer to continue and any LFOs or decays to continue to be computed, but no new notes will fire.

This code would go into Clock.cpp where you see:

Code: Select all

if (this->devices[i]->getNextTime() == t)
{
	this->devices[i]->reset();
}
Change it to something like

Code: Select all

if ((this->devices[i]->getNextTime() == t) && (this->resetDisable != DIGITAL_IN_NONE) && !digitalRead(this->resetDisable))
{ 
	this->devices[i]->reset();
}
Or something like that. Pausing the clock like you say is a little more difficult since the clock architecture is built on millis() - which is absolute time since the device was powered on. It's not impossible, but it's not easy. Once I get a slaveClock mode written, then it should be a little easier to implement a pause.

Extending individual devices to pause their events is very similar. Take a look at Trigger::reset() - same thing, just add a setter for a pin value, and when reset() is called, check that pin before doing any of that work.

This specifically is something that I've wanted to add... it makes the 'b a little more useful for being a sequencer that you can 'play' or step through parts of a song with... chorus, verse, bridge, etc. I have some other ideas in my head for things like sequencers that can have an array of sequences that you scroll through with an analog input or toggle through with a ditigal input...

If anyone is interested in forking and submitting pull requests for getting that type of code out to others, feel free!

I think Akrylik is right... a lot of what you can do with this is mainly utilitarian. Sure, there will be some wonky algorithmic stuff you can write, but most of the sketches I find myself wanting to do for personal use is more practical.

As to the USB power leaking onto the euro bus, unfortunately, the Due's power management circuit puts whatever voltage is powering the due on the Vin pin - which is connected directly to the +12 bus. I should have put a diode on there to prevent what you are seeing, but I didn't get that in before I ordered the last set of boards.

Disconnecting the USB before powering down will solve the problem.


-s

User avatar
Riggar
Wiggling with Experience
Posts: 464
Joined: Sat Mar 16, 2013 6:38 pm
Location: England

Post by Riggar » Thu May 29, 2014 8:39 am

Hi all - unit arrived safely and now installed. Lots of flashing LEDs - lovely!

Popped in the bluetooth dongle into usb slot - did a search found device -
Adafruit EZ-Link 010d.

This is Windows here (Win7) now stuck? - When I fire up Arduino IDE I get notification there's a bluetooth device that needs pairing and a code (tried the usual suspects, 4 blanks 4 zeros etc.) but can’t get past this?

What’s the answer? Thanks

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Thu May 29, 2014 9:12 am

Try '1234'

There are instructions here. I haven't tracked down a windows box to do a version of the instructions for the site:

https://learn.adafruit.com/introducing- ... r-and-test

-s

User avatar
Riggar
Wiggling with Experience
Posts: 464
Joined: Sat Mar 16, 2013 6:38 pm
Location: England

Post by Riggar » Fri May 30, 2014 9:02 am

Well 1234 did work in terms of paring ... BUT

I then spent several hours or so on 2 different machines trying to get something to load up - to no avail.

Always telling me 'no device found on COMN' - N being the one identified in the device properties as suggested in the web link above. This one ... (https://learn.adafruit.com/introducing- ... r-and-test)

This included with and without the additional 'boards' text. With it added (makes more sense) as Arduino Due (Bluetooth) appears as a board option

When I checked the web link, all of that made sense except I'd been working with a 2.0 Bluetooth dongle so I abandoned ship for the night.

Next day, today, I bought a Bluetooth 3.0 and 4.0 (the 3.0 was a good price and it'll be handy).

Once again using the 3.0 and 4.0 dongle on both machines, I always the same message - no device on com.

Incidentally, the software supplied for the 3.0 & 4.0 dongles did not require a pairing code.

Here' s the verbose message returned from IDE (1.5.6r2) - see pic

Now the status of the blue 'linked' light on the nw2s is interesting. Once linked by the method above and lit - as soon as an upload is run and the above error message returned the light flashes and goes out - never to return - unless a remove device followed by an add device process is gone through.

Additionally, the 4.0 software (Belkin) gives a little more friendly software including a pictorial representation of your Bluetooth devices. Always even with everything set correctly (device added, com ports set, blue light on) it shows the nw2s as NOT connected - when it appears it is?

Image


Finally in terms of buzzing around the net I found this ....

http://forum.arduino.cc/index.php?PHPSE ... c=167492.0

which waxes lyrical about issue surrounding the Due and not finding com ports - I'm not an expert so I don't know if this is relevant or not - but may be of interest.

So right now - stuck - any suggestions?

User avatar
akrylik
Super Deluxe Wiggler
Posts: 1907
Joined: Sat Feb 18, 2012 9:13 am

Post by akrylik » Fri May 30, 2014 9:06 am

That sounds exactly like what happened when I forgot to do the ERASEANDRESET step that is required for Bluetooth programming but not required for USB. See the last step of:

http://nw2s.net/uploading-a-sketch-with-the-ide/

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Fri May 30, 2014 10:00 am

One thing to double check is that the unit is programmable over USB. This doesn't take any special work as the USB chip does a hardware equivalent of ERASEANDRESET. Important sanity check.

So far in the multitude of Dues I've installed and tested, I've had only one that would intermittently not program. Not saying this is the case now, as by the time you get an assembled unit, I've uploaded at least 6 sketches to it over USB, but again, it's possible and programming over USB will confirm that's not the issue.


After that, since the ERASEANDRESET is a software-based reset, you will need to make sure, if you are writing your own sketch, that it has at least the EventManager.initialize() in the setup function and EventManger.loop() in the loop function.

Assuming that is all good, then here's how to test the BT communications without the IDE:

On OS X, there's a program called SerialTools. The BT will show up in it's dropdown. You can select it, select 19200 and then hit connect. The blue link light will show up, and if you hit the reset button, you should see the EventManager.initialize() debug output which is just showing all the variables getting initialized. Do the same, but instead of hitting the reset button, toggle the DTR flag up and down once, and you will see the same thing.

On Windows, there is an equivalent program called X-CTU. It's a serial monitor that allows you to connect to the 'b see the output and toggle the DTR pin which will force a reset.


Specifically about your question about the BT status light... this is a bit longer explanation. If you use one of the above two serial tools, then you'll see that the link light is very predictable. When you connect it turns on. When you disconnect it turns off.

SPP is a little different than usual BT connectivity in that when you first pair, The OS creates a virtual serial port. That serial port will live on your system until you manually delete the device from your BT devices in the control panel.

Even though the port is there... the connection doesn't exist until you explicitly open that port. The times this happen are when:

1. a serial monitor tool (SerialTools, X-CTU, etc) is connected
2. the Arduino IDE serial monitor is opened
3. the Arduino IDE tries to upload a compiled sketch

The link light will go out when the connection is no longer active. This happens when:

1. a serial monitor tool disconnects
2. the Arduino IDE serial monitor is closed
3. the Arduino IDE tries to upload a compiled sketch and either succeeds or fails, the light will immediately go out.


The confusing exception to this is that when on OS X (and front your description Win7 is the same) you pair the first time, the OS doesn't release the link until some other tool (either a serial monitor or the Arduino IDE) connects and then explicitly releases the connection.


Hope that gets you a bit further.

Let me know.

s

User avatar
2mb1o
Learning to Wiggle
Posts: 37
Joined: Sun Mar 09, 2014 4:32 am

Post by 2mb1o » Fri May 30, 2014 10:25 am

H Scott, I'm looking forward for the step 3 of the Assembly Guide.
I don't wanna make mistake and I think there is some difference between PCB and pictures (for instance 100kΩ trimmers and polarity).

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Sun Jun 01, 2014 9:10 am

I'll be finishing up the instructions next. There were a couple of late orders as well that I'm waiting on a small parts order to complete, so that also on it's way out.

I think all but four of the orders have left the manufacturing facility and will be showing up in racks shortly.

Anyway, I took a brief break from assembly and testing to start on the no-program firmware. This will open up the 'b to lots of folks who aren't programmers and for those who are, will make day-to-day work a LOT easier.

Anyway, I have a basic program working. It loads a JSON file from the SD card and sets up the devices and starts up all of the program. Here's what a simple JSON configuration looks like:

Image

s

User avatar
Riggar
Wiggling with Experience
Posts: 464
Joined: Sat Mar 16, 2013 6:38 pm
Location: England

Post by Riggar » Mon Jun 02, 2014 7:04 am

Ok – still no joy uploading sketches via Bluetooth.

Akrylik – ah! Thanks I missed this (note to self - just ‘cause its for Mac and I have a PC doesn’t mean you need to speed read!). I tried the ERASEANDRESET and complete blank – no feedback from the device

Re Sanity check. Yes fine I’ve connected to the Programming port and have successfully uploaded a sketch and had a play (great fun)

Scott – thanks for the details re the 'blue linked ligh't. It works as you’ve outlined. Opening the serial monitor in IDE lights up and closing - its out. Indeed when first added to Bluetooth the lights on until one or other of the actions you metioned.

I got hold of the X-CTU software…
The first thing I tried was to run the discover devices option – it never finds anything? Next I tried the add devices (add a radio module) and it asks to reset the device – but again nothing.

Note if I run 'add a radio module' when the IDE serial monitor is open I get this dialogue box (see pic) – not sure what this means?

I did find another piece of software to look at the Bluetooth connection - Bluetooth View – it always shows a connection error of 10049. Bluetooth port/channel or device address not valid according to Microsoft. (see second pic)

Image
Image

User avatar
Riggar
Wiggling with Experience
Posts: 464
Joined: Sat Mar 16, 2013 6:38 pm
Location: England

Post by Riggar » Mon Jun 02, 2014 9:12 am

Update - found this - does it help?

http://forum.arduino.cc/index.php?topic=141628.0

User avatar
mckenic
pew!pew!pew!kthnxbye!
Posts: 6364
Joined: Fri Aug 06, 2010 8:05 pm
Location: Limerick, Ireland

Post by mckenic » Thu Jun 05, 2014 5:25 pm

Mine arrived here in Ireland yesterday - Thank you Scott!
Got hit with import duty (but not hammered, about $100) and MAN I have to say I dodged a bullet!

I was thinking of the kit but am SO glad I went built - troubleshooting if it didnt work 1st time would have done my head in :hihi: Thank you Scott!

Not had much time with her apart from power-up and test 'factory' functions... watching with bated breath to see where/how you guys take this! I would like to 'port' the Arduino code thingy I did ages ago with AC coming out of the PWM pin to an OCS V/Oct... it was one of those Mathematic functions... I know Im not describing it right... you know where you do something like:

v=(v|((t>>4)+c)+t%18)/6+168,v|(v%222)

Anyway - thank you! Onwards and upwards!!!

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Thu Jun 05, 2014 5:31 pm

Wow. Sorry about the import duty. That's crazy! Since I can only insure it for the same amount as I claim for duty, I try to strike a balance there, so that's like 33% import duty??!?!

I know what you're talking about with the bitwise math oscillator.

I'm working on the no-code firmware at the moment, but after that, I'll be coding new controllers and oscillators. Feel free to add a ticket for it on my github page.

https://github.com/nw2s/b/issues

-s

User avatar
mckenic
pew!pew!pew!kthnxbye!
Posts: 6364
Joined: Fri Aug 06, 2010 8:05 pm
Location: Limerick, Ireland

Post by mckenic » Thu Jun 05, 2014 5:44 pm

Hey Scott!

No worries mate - I was expecting the import duty and hope you dont think I was bitching sir! Im just delighted it was not more :tu: & more importantly delighted with the built module - Thank You!

Anyway on to cool things... I know I have a LOT to learn but just wondering how difficult 'porting' Arduino sketches to the ::b ? Here is the code I hacked from an example online and I think a thread here on Muffs:

--------------------------------
#include <TimerOne.h>

// Pin Mappings
#define PIN_RF_ENABLE 4
#define PIN_RF_TX 3

unsigned long t = 0;

void setup(){
pinMode(PIN_RF_ENABLE, OUTPUT);
pinMode(PIN_RF_TX, OUTPUT);

digitalWrite(PIN_RF_ENABLE, HIGH); // Turn the transmitter on.

Timer1.initialize(4096); // sample rate
Timer1.attachInterrupt(gen_audio);
}
void loop(){} // We do nothing in the loop

void gen_audio(){
analogWrite(PIN_RF_TX,
t * ((t>>12|t>>8)&63&t>>4) // Algorithm here
);
t++;
}
--------------------------------

Anyhoo, thanks again sorry if this isnt the place for this discussion :tu:

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Thu Jun 05, 2014 7:04 pm

So theres an easy way... and then there's the way that I'd do it if I were incorporating it into the framework.

What I would do first is to take one of the test sketches as a template.

Keep the includes and the eventmanager stuff... I uploaded a template here...

https://github.com/nw2s/b/blob/master/s ... mplate.ino

I'm not sure what's in TimerOne.h, but the Due uses a completely different timer structure, so assume that you can't use that specific code...

You don't need the pin mappings as all of the IOs are defined in IO.h as enums.

unsigned long t = 0; that's fine... but on the Due, you only need int - both are 32 bit, but that's neither here nor there.

You will need a static variable there alongside your t. This will allocate and configure an output for you:

AnalogOut o1 = AnalogOut::create(DUE_SPI_4822_00);


You don't need the pinmode() calls. The event manager initializes all of the pins and peripherals.



Okay, your timer code is there. Let's table that for now. I wrote my own for my oscs, but there should be a simple timer library for the due by now...

Then there's your timer event handler...

void gen_audio()
{

instead of analogWrite, use your o1 variable that you declared earlier...

o1.outputCV(0); //outputCV uses mV values... this sets to 0
o1.outputCV(-5000) //this sets the output to -5V or -10V if you have the upgraded op amps. I haven't yet written code that will let you configure that aspect

If you prefer to use 0-4096 values, you can do that too

o1.outputCVRaw(0); // This sets the output to about +5V
o1.outputCVRaw(4000); // This sets the output to about -5V
o1.outputCVRaw(2000); // This sets the output to about 0V



}


So you get the picture...

Lemme look up some timer code for you. If you want to delve in yourself, check out:

https://github.com/nw2s/b/blob/master/s ... llator.cpp

Maybe this guy?

https://github.com/ivanseidel/DueTimer

Then like I said, it'll be easy to make one the right way since I have your code and create a voltage controlled sample frequency using the library framework in place... you'll just have to give me a little time for that.

s

User avatar
mckenic
pew!pew!pew!kthnxbye!
Posts: 6364
Joined: Fri Aug 06, 2010 8:05 pm
Location: Limerick, Ireland

Post by mckenic » Thu Jun 05, 2014 8:55 pm

:eek: Wow dude! THANK you so much for the reply!

It certainly seems from 1st glance (its 2:50am here :hihi: ) that you are radically simplifying what we need to include and declare in our Arduino sketches - this will be so, so, so helpful for non-expert 'pokers' like me who just like to mess around with the variables (I usually copy-paste headers & includes etc)...

Honestly between using a few Duemilanoves & a Mega I found compiler 16 would work with one, 22 only with another etc... it felt like a moving target and did not lend any confidence to investing more time than just getting basic functionality working! This on the other hand... :mrgreen:

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Thu Jun 05, 2014 11:10 pm

Yes, the general idea was that for hackers, they can do all kinds of stuff, but for tinkerers, the C++ should be easy to follow. In the next couple of weeks I should get the no-code version as well which will allow non-programmers to treat this thing more like the Reaktor of the modulars.

I remember now where I saw an osc like what you're describing clone45 is building something that uses those.

You can see some of the similar code here:

http://www.eurorackdb.com/node/1911/

Okay, so turns out it was pretty easy to implement using my oscillator framework. I have no idea if it sounds anything like what you had in mind tho. Clearly there's lots of room for improvement and more bitcode algorithms.

Here's the framework code... This is checked in to github now.

Code: Select all

BitCode&#58;&#58;BitCode&#40;PinAudioOut pinout, PinAnalogIn pinin&#41; &#58; VCO&#40;pinout, pinin&#41;
&#123;
	//TODO&#58; Add an integer parameter to indicate the iterator initial value 
	//TODO&#58; Add a parameter to allow an analog input to define the iterator offset
	//TODO&#58; Add a parameter that switches between algos

	this->currentvalue = 0;
	this->iterator = 0;
&#125;

int BitCode&#58;&#58;nextVCOSample&#40;&#41;
&#123;
	if &#40;this->phaseindex == 0&#41;
	&#123;
		this->currentvalue = this->iterator * &#40;&#40;this->iterator >> 12 | this->iterator >> 8&#41; & 63 & this->iterator >> 4&#41;;
		this->iterator++;
	&#125;

	return this->currentvalue;
&#125;
Then you can see the sketch here: (configures Analog In 1 as the sample rate and DAC 1 as the audio output)

https://github.com/nw2s/b/blob/master/s ... itCode.ino

And, if you want to test it out on the no-code firmware, then the JSON file will look something like:

Code: Select all

&#123;
	"program" &#58; 	

	&#123;
		"name" &#58; 			"Initial Bitcode Demo",

		"devices" &#58; &#91;
			
			&#123;
				"type" &#58; "BitCode",
				"dacOutput" &#58; 1,
				"analogInput" &#58; 1,
			&#125;		
		&#93;
	&#125;
&#125;
Last edited by scottwilson on Thu Jun 05, 2014 11:18 pm, edited 1 time in total.

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Thu Jun 05, 2014 11:17 pm

I realize I'm not being a very good teacher here because 1. I wrote the code for you and 2. I think you really wanted to learn how to write a standalone sketch, not muck about in the framework code

For that I apologize, but I was intrigued to know what it would sound like.

Here's a quick recording I threw together:

https://soundcloud.com/scottwilson/quic ... -the-nw2sb

clone45
Common Wiggler
Posts: 144
Joined: Sat Oct 10, 2009 1:28 pm

Post by clone45 » Fri Jun 06, 2014 6:16 pm

Hi everyone,

As Scott mentioned, I am building a module based on ByteBeat. You can see some of the equations I used here: https://github.com/clone45/EquationComp ... ations.cpp

I don't want to hijack this thread, so I'll leave it at that. If you have any questions, feel free to email me at bret@microbemodular.com

User avatar
mckenic
pew!pew!pew!kthnxbye!
Posts: 6364
Joined: Fri Aug 06, 2010 8:05 pm
Location: Limerick, Ireland

Post by mckenic » Fri Jun 06, 2014 6:33 pm

Jesus today just COMPLETELY got away from me, no time to do the things I have meticulously planned! (anyone else finding that - you poke your head up and go "Huh - where is the day gone?" Must be a getting close to 40 thing!)

Anyway, Thank you Scott! Sincerely that is great! I can understand the code I posted so now I have a solid, working example for the ::b to learn from AND your OSC template to learn from - I seriously couldn't ask for more! Thank you!

clone45 - thats really cool any more info please?

This is the kinda thing Im hoping to generate -CV for my Cyclebox :hihi:
http://soundcloud.com/mckenic/arduino-a ... to-modular

Anyhoo - thank you again!

User avatar
scottwilson
Wiggling with Experience
Posts: 432
Joined: Mon Sep 16, 2013 12:54 pm

Post by scottwilson » Fri Jun 06, 2014 10:14 pm

So I've been playing with some of these bytebeats and the word size actually has a bit of an impact on the sound (and the correctness of the sound)

Right now, I'm playing with that a little bit, but I've at least gotten a couple fo clone45's equations sounding like some actual beats, so that's some progress.

More later, just thinking about it as I clean up around here.

s

corprod
Learning to Wiggle
Posts: 29
Joined: Tue Dec 24, 2013 3:17 am

Post by corprod » Sun Jun 08, 2014 2:45 pm

So I think I'm done building the kit. I had to figure things out based on some of the pictures people have sent, but it powers up, the reset button resets it and other than all of the analog output leds staying on it seems to be stable.

So...what I'm looking for is a nw2s for dummies for getting a sketch uploaded. I can pair with the bluetooth. I have gotten the Arduino and STL software installed but I'm not sure what to do with the Codebase (what to download, where to put it). Also the tutorial, mentions a modified boards.txt file, but no instructions as to where and what to do.

Basically, what do the people who bought the preassembled kit get as far as instructions, sketches, etc. I feel like an idiot but I really don't know how to proceed.

Thanks!
Andrew

Post Reply

Return to “nw2s”