Very interesting paper, and I'm interested in building one. From looking at the Board product, it's clear that aesthetic appreciation is a consideration ;) I'd like to build the prototype into a 6-7" square box to match a monome kit. I think that scaling down the antenna dimensions would impair or stop it functioning, and the best way to do this would be to reduce the number of strips to make something like a 6 x 6 matrix, although that might be musically useless. Could you advise?
How feasible would it be to give it tuned onboard oscillators to drive the antenna and mix the output into one audio output stream?
My advice to everyone is to experiment with one junction first, in the geometry you are thinking of making. I think smaller strips could be OK. It depends on a lot of things like what amps you are using and what the voltages are.
I think a 6x6 matrix would be useful-- even a 2x2 matrix could be a good single-touch xyz sensor with the right geometry of strips.
I thought of using some kind of oscillators in the Soundplane but the best solution was using the DSP to produce all the frequencies. In general I think using the DSP is more flexible --- with Arduino or something like that you could probably make at least a few oscillators in software.
Thanks for the advice. I acquired the remnants of some adhesive copper tape some years ago, and this looks like a good way of using it.
I note you used aluminium foil for the ground planes: presumably, there's no reason why this couldn't be done with adhesive copper too.
I'm unsure as to whether or not the ground planes need to be on separate layers relative to the antenna strips. The diagram in the paper suggests that a ground plane and antenna strips can all sit on a polyester sheet, but the layer listing suggests the aluminium foil may be a separate layer.
I quite fancy covering it with a piece of hide as used on traditional drums: an experiment needs to be done!
Anything conductive is fine.
Actually in the current Soundplane the ground plane strips between the pickups in the same plane evolved out of existence. All that is needed is a little space between the separate pickups. A grounded plane behind the whole thing ( on the opposite side from the carriers ) is needed for shielding. You definitely want the pickups in the middle for noise reasons.
I really want to see your hide-covered Soundplane so keep in touch!
Hi Randy, I thought I'd get the difficult stuff out of the way first, and generate the objects for Max: as luck would have it I run Windows XP and have only ever compiled one thing in C.
So I had a go with the simplest example in the Max 5 SDK and using the instructions for cygwin here:
this appears to compile fine with MSYS (left over from abortive attempts to compile something else) - which co-ordinates gcc compilation. Hurrah. However, not so straightforward with the objects downloaded from here, and I could use a little hand-holding.
Lacking a centroids.c file, I can get it to 'engage' with the centroids~.cp file, but it throws up a shedload of errors, including not being able to find some jit stuff. Potentially, there's a lot of combinations of file in folder which I can try, but if I'm doing something obviously wrong, I'd like to know. If the answer == use MS visual C++ express that will be possible, though burdensome.
I put the ml_k1_centroids~ folder, and the ml_jit_utils folder in the SDK examples folder
I used the Max 5 SDK because I had it on a hard drive, happy to use 6 or 4 though.
I now have visual c++ installed and running, so it could be part of the solution.
For testing a single junction of your design, I would just make a Max patch that puts out a single sine wave for the carrier and then looks at the amplitude of a single sine wave coming in.
It's been a long time since I've looked at that centroids code. I don' t know what you have, exactly. I would make sure you can compile the max and Jitter example objects from the SDK first. If you just have that one .cp file I can probably dig up something better, with a help file even.
Hi Randy, Thanks for sticking with this.
I'm happy to experiment with materials and signals, but see the Max Patch as equally important as the hardware. Compiling the Max objects is the big unknown for me, so I would like to know that there is a destination.
If you can dig up something better, I would be grateful, and give it my best shot.
In your current source files, the jit-utils folder seem to have ordinary c++ files, which I can read in notepad++, and will have a go at compiling next. The other three folders have stuff which I don't recognise, and can't open in human-readable form in a text editor, so I'm not confident that they provide anything that can be compiled in Windows.
[edit - 30 12 12] scratch the above para. I can open the .cp files in notepad++ - not sure why it failed the first time.
I'll be happy to share back any working Max objects that emerge for Windows.
To make these objects on Windows, you will need to install the Max/MSP/Jitter SDK for Windows. So the first step is to download that and then make one of the example objects for Windows, like plus~ or whatever is in the SDK, and make sure you can run that in Max on Windows.
I have never actually compiled a Max object on Windows, so you will find better help from the C74 forums on this point.
Obviously, I wasn't clear; I did download the MaxSDK (for Max5) and compiled the simplemax example using MinGW (containing MSYS) following the C74 instructions for using Cygwin.
I have now replaced the Max5 SDK with that for Max6 - the directory structure seems slightly different, but I think I got past that.
As you suggested, I have compiled the 'collect' source. It appears to have compiled and works (stacking up the inputs in the order in which they are clicked until banged via collect into the message box, or giving a count of how many input clicks since the last bang). Simple stuff, but I'm quite chuffed to see it working.
The SDK collect example includes some instruction, the key thing being that one simply gives a 'make' command in the MinGW CLI, rather than a long string of commands and modifiers, because this is a C++ file.
I tried my new tricks on ml_jit_utils.cpp
It looks like I will need to create a makefile, and have busked one from the collect example to try and compile ml_jit_utils, since this one has readable source files. The process falls over in trying to find jit.common.h and z_dsp.(file extension) which are in the jit_includes and msp_includes folders of the SDK. I suspect there is unnecessary content from the collect makefile, as well.
This may take a while.
[edit 30 12 12]
note edit in earlier post.
VCC 2010 beckons as the way to build and link the project.
Just touching base to let you know I haven't given up on porting the code; bit of a journey though.
I've switched to using MS VC++ 2010 express and am using the Max 5.1.7 SDK, and am compiling by a process of elimination: follow the compiler output, and address the code issues. It feels like progress, and I've found at least one blooper in the SDK.
I'd appreciate some guidance; your source provides four folders for jit_utils, mesh, process, and centroids - I'm trying to compile the .cp files in each of the folders:
Should I compile them in a particular order?
Do any of them depend on another to compile?
Following on from my previous post, I've got a couple of specific questions:
You have a folder and files called "ml_jit_utils.h" but also #include "ml_k1_jit_utils.h" in some other files. Am I right in thinking these are one and the same file?
ml_k1_mesh~.c includes this file "ProcMeshWGM.h" but it is not present in the downloads. Could you clarify how I should proceed with this? Is it something that is generated from an initial compile of something?
Sorry I didn't notice your post until now.
I don't see either of these filtes on my disk and I believe they were renamed, or dead ends. I would try removing the #includes and if the code compiles without them, you are good. If not, let me know what functions seem to be missing and I will get you those!
The relationships between .c(pp) and .h files should be given in the files themselves, in other words what is including what. So order should not matter and if you put them all into a project they should compile.
Sorry for the state of the code! It's fairly old and I guess no one has tried this before. It's good you are on VC++2010 Express because that's what I use for Windows too. When you make your way through this I will definitely post a cleaner version with what you've learned.
Thanks for the advice.
I wanted to confirm which objects I should focus on compiling and so tried loading the max patches into Max5 (without any objects to see which errors it gave for unfound objects. It couldn't find the mesh~ and process~ objects. From this I deduce, these are the only objects I need to build, with centroids being unnecessary, and the jit-utils.h file being the only item needed from that folder. Should have done that first eh? :-\
I commented out the ProcMeshWGM.h include.
compile for both mesh~ and process~ stop with a load of unresolved symbol errors, whilst the compiler is compiling a library and object. I'm pretty much out of my depth with that.
I have compiled a number of the examples in the SDK, and they all compiled fine, and I checked in Max that they do actually work. I did a jitter object as well just to be sure.
So: process~ and mesh~. What I've done is start with the 'collect' example in the SDK, and replaced text 'collect' with 'ml_k1_mesh~/process~' as appropriate, and renamed files as appropriate. Then brought in your source files, renaming .cp as .cpp for process and .c for mesh~ (just to see if it made a difference - changing all the references as appropriate in the 'collect-originated' files.
Next I use VCC express to open the solution file (originating from 'collect' but with new text), following which it goes through a conversion process. mesh~ converted with five benign errors, process~ looked a little murkier, but progressable.
I had to go to project properties and add the jit-includes folder to the max and msp-includes the VCC-general properties and Linker properties. jit-related errors are eliminated.
So I have a couple of folders with the files all dressed up and nowhere to go.
Happy to share the results so far. I really don't know where to start looking for the unresolved symbol errors.
The mesh~ object does waveguide mesh synthesis, so you may not care about that? The process object is there to do scaling and calibration. It doesn't do anything too tricky, just some scaling and filtering. It is an external instead of a Max patch just because it's cleaner and easier to change that way.
What you're doing with the code sounds a bit frustrating with not much tangible results. Why not forget about the Max objects for now and just use patching within Max to make a 1x1 matrix. Then you'll have some experience and something fun to play with. When you get bored of that you can make a 1x8 matrix or something, which could be a really useful tool and also wouldn't need any custom objects.
Within a couple of weeks I'm publishing the source code for the current Soundplane software. This should be much more pleasant to work with. Maybe you could get more people interested in helping with a version of the new Soundplane software that works with your audio interface build.
Hi Randy, You're right about the code side being frustrating, but I think it's fair game if I'm going to mess my n00b hands in the murky depths of C. I have a list of things to check through to see if I can resolve these external objects (finally trying the microsoft site's advice).
However, I have also started researching the materials to build a prototype, and I have MOTU traveller, so there shouldn't be problems in doing the audio tricks to test it. And I need to figure out the design aspects of getting things into the case of my choice (to match my old monome kit, of course).
I shall be interested to see what you do with the soundplane software. Thanks for releasing this stuff!
Jumping way back to the question about tuned onboard oscillators...
It's theoretically possible to do it this way, but the challenge becomes tuning that is both precise and won't drift over time with temperature, power supply, or other changes. For best results, you need each carrier to occupy a different bin in the FFT output. Unfortunately, if even one carrier oscillator drifts from its optimum frequency, it will be smeared in the FFT across multiple bins, giving false triggers for all the other carrier frequencies.
Your best best is to use sampled digital oscillators, locked to the same rate as the A/D for the sensors. In this way, you can be sure that each carrier occupies exactly one FFT bin without any smearing. There will be enough noise floor to keep you challenged without the extra hurdle of precise, steady tuning.