Hi

I'm trying to extend the functionality of my APC40. To do this i would like to capture the midi data from the device and send it via the IAC driver to Ableton Live. With a second Bus of the IAC driver i would like to pass the signals from Ableton Live via pd to the Device.
But this doesn't work for me.

The first Problem is that I'm not sure if the bidirectional communication works. I've read in this forum that pd uses the first 16 midi channels for the first device and another 16 channels from 16 to 32 for the second device.
So i made the APC40 my first input device and the IAC Bus 1 my first output device. IAC Bus 2 is my second input device and my second output device is the APC40. Then i only connected all midi ins that are described in the help file with the midi outs.
While doing this i've noticed that no sysexout exist.

This leads to the second problem.
APC40 and live do a handshake. but this handshake doesn't work in my case. I think this is because no sysexout data is passed through.

I hope I described my setup understandable and you could tell me if the bidirectional communication works the way I've tried to get it to work and if you know how to make the handshake work.

Mayb one of you has already solved this problem. It would also help me if you know a way to intercept the communication without pd. But it would be great if it works with a free tool.(I know that it could be done with bome's midi translator)

Hi, I am just starting with arduino, and still not very experienced in PD.
I have found tons of great info around here, thanks for that.

For me, everything works up to a point:
* I successfully upload the Firmata
* the output example in Processing works, I am able to turn pin 13 on and off
* in PD I open the correct port ("[comport] opened serial line device 3 (/dev/ttyUSB0)")
however, I have not been able to get any communication with the arduino in PD using Hans-Christoph Steiner's [arduino] - either turn pin 13 on/off or get firmware information. The numerical commands sent to [comport] seem correct, e.g. 249 for version information, etc.

So, the only place it seems possible to be going wrong is either [comport] or after that, along the line. As I said, it works with the same port from Processing, and at the same rate - 115200
"get_baud_ratebits: 115200.000000
set_baudrate baudbits: 4098 /***(what does this second line mean?)
[comport] opened serial line device 3 (/dev/ttyUSB0)"

I am running Ubuntu Intrepid, latest versions of Pd-extended, Arduino IDE, Firmata. The board is old though, "Arduino NG or older w/ ATmega8" but I guess this doesn't matter if the above mentioned things work.

I still have to test it for input, but I have to pick up some sensors from the shop.
If [arduino] does not work out I may try Messenger, but it really seemed quite good for what I am trying to do (drums with input from piezo elements).

edit:
This *may* have been due to a bad Arduino board, because I am now unable to transfer any sketches to it. Surprisingly though the Processing example still works (Firmata is left on the board from the time transfers worked)

I think I've read everything there is out there on this subject on mailing lists, forums, etc., but I'm so sad that it doesn't seem to be going anywhere that I just have to ask again. Is anyone still trying to get wacom intuos3 tablets working in pure data on mac os x?

I understand the problems, to a certain extent (e.g. wacom's whacked driver), although I'll freely admit that my low-level technical knowledge leaves off after a certain point. But it seems like it's so close. The wacom driver doesn't work with hid, but does work with various other mac os x software (e.g. photoshop), so I wonder how it might be possible to hijack the events these other programs are using...

Sorry, maybe I'm being too optimistic, but there's one particular project I'm working on where getting x/y, pressure, distance, tilt_x/tilt_y data would be so perfect it's beyond belief... far better than a wii. I'd be willing to put quite a bit of work into getting this done, so if there's anyone working on this and there's any way I can help, let me know.

Thanks,
Alex

> What protocol should be used to communicate with PC??
> MIDI isn't slow?

MIDI is not just a protocol, it is an entire communication system from the physical layer right up to the data layer including baud rate and connector specs. MIDI as a protocol could be run much faster over USB2 or ethernet, but a sensible modern extension to MIDI would encapsulate it inside OSC or something like that and send it over a session aware layer. MIDI has had 20 years and now it's probably best to just bypass it and go straight for OSC over ethernet. That would also bypass all those "driver" issues for Windows users too.

> I plain to use Linux!!

An excellent choice if I may say so sir! Perhaps it's time to look at Linux SBCs with built in network and USB. You can get tiny ones that are no bigger than a matchbox and single chip FPGAs that you can write your software into. Check out http://linuxdevices.com/

> I am having problems in getting an turntable to electrify with this
> electronics hardware

You will not drive a turntable motor from USB. The current demands will kill the source. You need an external PSU. 12v at about 1 amp is probably plenty.

> Should this project be commercial?? I would pay to someone that made for myself
> the turntable in wood, plastic or metal. Where can I find such shop?

In your garage. There's no reason not to start a small commercial enterprise making these things but you need to do a bit of defining exactly what the function is, who will buy it and in what parts of the world. My honest advice at this stage is that you don't yet have a saleable product. Needs more development. It's a great project and demonstrates ingenuity in using the optical sensor, but you need to very clearly define the exact function and software it is designed to work with and why. In a funny way you have to think in reverse. Start with the constraints. The target customer is the overall most important consideration. Choose the biggest group like Reaktor users and build it for them. The housing is probably the single most important design factor. Guess how many units you might sell and design around that. A thousand is a reasonable prospect from a website shop, over a year or two. You need to work out the labor costs for manufacture, how long will it take you to build each one? Maybe you can do a deal with a manufacturer to buy and retrofit existing turntables for a first low volume project. Or change the design to be a turntable accessory because many people already have an old turntable in their junk room.

Before getting anything manufactured you need a serious prototype, something you can show to an engineer who can give advice on large scale production. Product design is a lot of odd things you never thought of before, but many are common sense. Heat dissipation, EMI shielding, where to locate certain components for accessibility, physical strength, vibration. If you want to sell a product in most countries it needs to pass some basic safety requirements. Having external power supplies will solve 90% of these in one go. The most expensive ways are injection molded plastic. The best ways in the modern culture are good old fashioned wood and metal, renewable and recycleable materials. Do some cost calculations for folded steel box sections, extruded aluminium and plastic housings. Think about assembly all the time. Contact local engineering companies and get quotes, they are always happy to send single samples for free if you are serious. Use standard components wherever possible. Be creative in reusing things that are already mass produced and adapt them to the design. Think about weight because of shipping costs. Look at your competition all the time too. Think about why people would buy your turntable in preference to one of those DJCD boxes. How will you market it, what are the key features? The good news is that because of the economy in the US there will be a renaissance in small manufacture over the next decade. People have got used to the idea that we just design stuff in the West and let the Indians or Chinese build things. That economic pendulum will swing back and we find there's a shortage of skills in manufacturing. Getting a good base in product design now could pay rewards further down the road. Most first business projects are unsuccessful, don't let it knock you back. The second or third project is the one that pays.

hi brett, that track is still up on my site. for some reason the link comes out as a .pd file not an .mp3

http://www.m-pi.com/this-is-serious-mum.mp3

just cut and paste that and it will work.

also heaps of stuff here: http://www.m-pi.com/remixes

>It's weird that many ppl seem to be using pd but that the output~ page in the forum still has threads in it from 2004 in the top page!! <

it took me a few months of solid patching (a few hours every day) to get a workable setup for actually making tracks. it's certainly no small undertaking.

>I'm pretty new to pd and just working my way through tutorials at the moment, but do you have any tips with regard to actually going about customising your own setup?<

you are on the right track going through the tutorials. the way i did it was first to build stuff to cut up and effect samples, and then secondly make a system to control those processes live. mine was all based on the [key] command, and i just triggered everythign from my laptop's qwerty keyboard. this was nice when i was travellign as it meant i didn't need to cart any gear around. also good for playing live cos i could pick my computer up and jam on the dancefloor. there are a few options though, especially triggering stuff with sensors and such. but i'm sticking with the bare bones keyboard approach cos it works for me well enough.

> like whether to keep lots of separate instruments or try to keep everything under one roof...<

i try to keep my stuff in one patch as much as possible. a couple of reasons for that, but the main one for me was that i kept modifying abstractions and then other patches that relied on those abstractions would stop working. generally much easier just to have one or two or a few patches to do everythign you need. even if you incorporate everything you make into one patch it doesn't get too big. usually well under 1 meg.

>I think I will tend to mainly use samplers and control structures for controlling my external Midi gear, but in a live setup, not sure how to integrate it into Logic Pro?<

my thinking on this is that if you have a guitar it has 4 or 5 strings, and you manipulate those strings in a variety of ways to make most of the sounds you need. if you listen to my audio..all of that is just 2 or at most 3 channels! so i always have only 2 or 3 samples playing at once. my stuff from back then was a bit light..not really hard hitting on a dancefloor (which is what i'm interested in) ..but i think you do what to keep everythign as minimal as possible. as far as live performance goes, i wouldn't go anywhere near something like logic audio.

if you have midi gear, then def work on triggering that with pd. i'm working on synthesis within pd now, rather than the sample based stuff...but it's a constant battle to keep cpu usage to a minimum. triggering external devices will be no problem for pd and will leave you heaps of cpu for doing sample mashing.

can't stress enough though. KEEP IT AS SIMPLE AS POSSIBLE. for live music, traditional musicians only play one instrument at once. if you want to make whole songs live, then you are going to have to do the beats and bass and interesting stuff all at one time, so you want to keep it as simple as possible so that you can inject a lot of liveness into it. generally, the more channels of audio you have going at once, the less room there is for jamming out in an impromptu fashion....unless you have magic fingers.

>Look forward to hearing your stuff if possible.<

cool, thanks. quick background on my stuff..."this_is_serious_mum" is a live jam recorded in one take. just 2 channels of audio driving all the sounds from small sample loops being cut up in realtime by me pressing keys on the keyboard. it's a super simple setup, but i think the reason why it works ok is that i spent more time actually playing and practicing than i spent on coding the bastard. i toured across europe and japan and australia playing this stuff and it was generally well recieved. at really good gigs it was the biggest rush ever.

so yeah. good luck. grab the bull by the horns and just go for it.

Cheers,

matt

hi forum.

we proudly announce the first public release of our compact composer
for pd, mmm.
grab it at http://netpd.org/mmm-0.1.0.zip
mmm is best described in it's faq, see below. don't expect too much
yet, there is still a lot to be done. comments, bugreports, cash, are
welcome.

have fun with it!
christopher charles & enrique erne

faq for mmm-0.1.0 - eden

what is mmm?
mmm is a pd patch collection aimed at providing a studiolike(?),
streamlined, dynamic interface for making synthetic music.

screenshots?
http://www.netpd.org/mmm.png
ymmv depending on your operating system. we put some effort in
detecting the operating system and setting the fontsize according to
it, but quirky xorg or dpi settings might screw things up again.

where can i get it?
we currently host the mmm at http://netpd.org/mmm-0.1.0.zip ,
alternatively, you can grab netpd, enter the chat, and if either of
the authors is online, download it directly through netpd and start
rocking.

what does "mmm" stand for?
mmm was originally just the working title, but we came to like it
somehow. the original meaning is "music making machine" but you can
substitute every m for whatever you want. so "massive multiplayer
music" is okay with us, too.

what is the inspiration?
having worked on/with the bagoftricks (lots inconsistently coloured
gop-patches to be connected freely) and netpd (lots of
inconsistent-looking windows to clutter up the screen), we came to
mock up an clean, dynamic interface in which modules don't bring their
own gop or open their own window, but log onto the interface that's
provided for them by the motherpatch. all modules sharing the same
interface made it easy for them to share the same sequencer and
arranger.

what are the dependencies?
mmm should work with pd-0.39 and zexy installed. iemlib is important
for many synth and effects patches, and there's even set of gem
modules you can chain if you want.

is it actually usable?
no. this 0.1.0 release is rather a tech demo and a taste of things to
potentially come. you can crunch some acid loops out of it already,
but don't sell your protools studio equipment to start working with
mmm on monday.

how does it work?
mmm's interface (mmmmain.pd) is divided into 3 parts: there is the
module/channel view, where you can chain up synths and effects on 8
different channels. select an empty field on a channel, and then use
the scrollbox on the left to select a patch and open it. when clicking
on a patch you loaded up in the module view, the 2nd view comes into
play: from there you control the patch's sliders on the left, right of
it is the stepsequencer for each of the slider (means everything is
sequencable!). yet you won't hear anything until you did the following
2 things: press play in the uppermost row of mmmmain, and set up the
arranger to play the stepsequence. the arranger is not module-based,
but controls all modules of a channel are grouped in the arranger. for
now, you can only select pattern 01 or nothing to play in the
arranger. so set up a loop for the first pattern (loopstart:0,
looplength:1) set the first field on the channel you got your patch on
in the arranger to p01 and start making some noise.

does it work online?
yes. mmm is compatible to netpd and will automatically log on to
netpd's server if you have the netpd chat open. you can also download
the whole mmm package through netpd. feel free to jam around the
world.

what's not working yet / what is planned?
as for now, there is no support for samples whatsoever, it isn't
planned to support them soon. further, there is no hard disk recorder
available yet, but it is planned. the arranger/sequencer combo is very
crippled at the moment, only supporting 1 16-step-pattern to choose
from and 1 page of 16 patterns in the arranger. this will change
rather soon. next there are plans for luxury editing functions,
especially in the sequencer like copy, paste, random pattern,
interpolation and so on. plans exist for full keyboard control, but
this will be worked on not too soon. the module roster is far from
being complete yet, more is to come.

can i save my stuff?
should be possible with the buttons above the channels. don't rely on
the result though, this is still 0.1.0

can i add my own modules?
modules are not to hard to write, but for now, the list of selectable
modules is hardcoded. look at all the 4m-* patches in the patches
folder to see how they are ticking. contact us for adding your patch
to the mmm or try to figure out yourself how it works

what's the license?
mmm is licensed under the gnu lgpl. if you think this is a too useful
product to be free of charge, please consider donating the amount of
money you would've paid for it (or the amount of money you got from
selling your protools equipment on monday) to a trust of your choice.

who are the authors?
mmm is developed by enrique erne (eni, swiss, pd{at}mild.ch) and
christopher charles (syntax_tn, germany, chr.m.charles{at}gmail.com).
we can be contacted via email, irc (#dataflow) or directly in the
netpd chat. several patches within mmm are based upon netpd versions
of them, check netpd for the original authors. mmm shares some of it's
netcode with netpd, by roman haefeli.

disclaimer.
we cannot give you any guarantees on using mmm, not even that you
have fun. it should be relatively harmless, but don't come crying to
us if mmm accidently hijacks your *mule and downloads david hasslehoff
recordings to your computer.

eofaq