This is a cross platform alternative for synchronizing two(or more) different computers to one Midi Clock.
Since one will have coge this will be between a Mac OSX and windows running traktor that produces midi clock.

For windows Midi Yoke (tested in XP) to wrap Midi clock to Pure Data extended (tested with v 0.41.4) from there the clock will be sent has an OSC message to one or all network computer(s). On the listening side there will be one other Pure Data patch converting a specific OSC message to Midi clock. Then coge can catch this midi clock just by clicking "Midi clk".

This is nothing special but it took me almost 3 weeks to accomplish it. Given that i knew nothing about pure data at the time, this site was very helpful. All examples were gathered from here.

Also note that this is not the best way.

There are Midi cables for this.
There are usb to midi converters, for those who don't have midi ports. Also external sound boards quite good with several inputs and outputs.
I have experienced a +/- 3 Beats float of BPM count on coge but always around the correct number, over time this seems to float less.
This still lacks testing.

Anyway.
You'll need Pure data extended on every machine.
You'll need Midi Yoke on Windows.
You can use Yac Driver on Mac OSX for midi wrap.
Don't know for linux, sorry. (read somewhere something about jack)

On pure data you'll need to define the midi device input or output which ever is the case.
On windows it's easy on any pure data windows you can set midi devices, choose midi Yoke (the channel number should be the same in the receiver input and sender output).
On OSX it's on the main window, under preferences.

If using this with quartz composer one can skip the pure data on the OSC server side (which is the one that listens). If adding more functions to this keep in mind that quartz composer does not understands 0 arguments messages. (I think this should be a bug)

You are advised to change the IP on the pure data patch to which ever is your destination. You can use 0.0.0.0 to broadcast. Don't use wireless, it's a 0 security communication protocol.

Hope to save someone's time. GL

http://www.pdpatchrepo.info/hurleur/OSC_MIDIclk_sync.zip

@Maelstorm said:

If you're on OSX, jack can be used as an insert plug-in so you can avoid the separate tracks, but you still get the latency.

which you can, depending on your host, eliminate by setting the track delay for the track with the plugin. So if the buffer is 512 sample/11.82 ms then set the delay to that and it should be spot on.

I've had the whole Jack graph latency explained to me numerous times by Stephane Letz and it still doesn't go in.....Heres what he told me...

> > Its the Pd > JAck > Ableton latency. (Ableton has otoh 3 different
> > ways of manually setting latency compensation - I'm just not very
> > clear on where to start with regards to input from JAck)
> >>>>
>
> This is NO latency introduced in a Pd > JAck > Ableton kind of
> chain; the JACK server activate each client in turn (that is Pd *then*
> Ableton in this case) in the *same* given audio cycle.
>
> Remember : the JACK server is able to "sort" (in some way) the graph
> of all connected clients to activate each client audio callback at the
> right place during the audio cycle. For example:
>
> 1) in a sequential kind of graph like IN ==> A ==> B ==> C ==> OUT,
> JACK server will activate A (which would typically consume new audio
> buffers available in machine audio IN drivers) then activate B (which
> would typically consume "output" just produced by A) , then activate
> C , then produce the machine OUT audio buffers.
>
> 2) in a graph will parallel sub-graph like : IN ==> A ==> B ==> C
> ==> OUT and IN ==> D ==> B ==> C ==> OUT (that is both A and D are
> connected to input and send to , then JACK server is able to
> activate A and D at the same time (since the both only depends of IN)
> and a multi-core machine will typically run A and D at the same time
> on 2 different cores. Then when A *and* D are finished, B can be
> activated... and so on.
>
> The input/output latency of a usual CoreAudio application running
> is: driver input latency + driver input latency offset + 2
> application buffer-size + driver output latency + driver output
> latency offset.
>

this next part is the important bit i think...

> For a graph of JACK clients: driver input latency + driver input
> latency offset + 2 JACK Server buffer-size + ( one extra buffer-
> size ) + driver output latency + driver output latency offset.
>
> (Note : there is an additional one extra buffer-size latency on OSX,
> since the JACK server is running in the so called "asynchronous" mode
> [there is also a "synchronous" mode without this one extra buffer-size
> available, but it is less reliable on OSX and we choose to use the
> "asynchronous" mode by default.])
>
> Stephane
>

Hello,

I recently noticed that recent versions of pd (both vanilla and extended) and other portaudio-based applications (e.g. Audacity) don't see some ASIO drivers: namely, the RME Fireface 800 and Reaper's ReaRoute ASIO drivers.

I found several posts in different forums around about both issues, and I've drawn the following conclusions:

• the RME driver ASIO driver simply doesn't work, and nobody actually knows why. However some people report to get ultra-low latencies (3ms) with the MME (or MMIO as in pd) drivers. Moreover, they can use the multi-in multi-out capability of the RME only when set at 48000 Hz (but this is another story...) I will ask RME directly about these issues.
• the ReaRoute ASIO driver is blacklisted by portaudio (as of v19) and therefore discarded...
  This is the most urgent issue because I need to route audio from pd to Reaper with the lowest possible latency/cpu load.
  Please help!

Hey everyone.

You'll have to excuse me 'cause I don't have a clue about PD, but need to use it for one of my current projects.

Basically, I want to project some text from my computer onto a blank canvas. I want to use a pressure sensor to detect when a user is sitting down. Once it knows someone is sitting down, I want the text to change.

From here on, I want the text to change after a given amount of time... say... 30 seconds for now?

When it gets to the last slide of text, I want it to do nothing other than display this line of text, until the user places their hand over an LDR. When the user's hand is placed over the LDR, the light will be reduced to a certain level. Once this level is reached, I want PD to time for 15 seconds, and at the end of the 15 seconds, illuminate any random combination of light bulbs and set off a rumble pack beneath where they have put their hand. If the user removes their hand before the 15 seconds is up, I do not want any of the light bulbs to illuminate, and I do not want the rumble pack to go off.

[When certain bulbs are illuminated, I want certain lines of text to be projected.

Say bulbs 1 and 2 are illuminated, but 3, 4 and 5 are not. I would like text to be projected that says "Bulbs 1 and 2 are illuminated. Bulbs 3, 4 and 5 are not". Or say Bulbs 1, 3 and 5 are illuminated, I want text to be projected that says "Bulbs 1, 3 and 5 are illuminated. Bulbs 2 and 4 are not."]

If the user stands up at any point in time, removing pressure from the pressure sensor, I want the initial line of text to be displayed on screen again, and everything to start over.

Sorry if this sounds very complex, please let me know if you can help out at all.

Edit ::

If it makes it any easier, you could ignore the bit that I've put in the square brackets. Instead of this, I would just like one more screen of text to be projected when any combination of the bulbs are illuminated.

Finally, it's done! The most polished release of Pd yet. We are further refining Pd into a truly powerful and usable programming platform.

http://puredata.org/downloads/

This release is dedicated to Jamie Tittle, aka tigital, who recently died of cancer. He was a long time and key contributor to Gem and Pd in general, even while he was in the hospital undergoing treatment. He is sorely missed in this community, and I am sure by many others.

Some highlights of this release:

* more functional namespace tools ([declare] and [import])
* new appearance designed to enhance readability
* GLSL shader support in Gem
* usability improvements
* on Mac OS X, you can now build "standalone" applications
* standard locations for user-installed externals
* many bug fixes

Here's the rough changelog:

• next visual appearance designed for readability

• default locations for user-installed externals, helpfiles, etc.
  GNU/Linux: /usr/local/lib/pd-externals and ~/pd-externals
  Mac OS X: /Library/Pd and ~/Library/Pd
  Windows: %ProgramFiles%/Common Files/Pd and %UserProfile%/Application Data/Pd

• lots of standard key bindings added:
  Enter/Return for OK
  Escape for Cancel
  Ctrl/Cmd-W closes all windows
  on Mac OS X, Cmd-` cycles thru open windows
  on Mac OS X, Cmd-m minimizes windows
  Ctrl/Cmd-R raises/lowers Pd window
  Ctrl/Cmd-Shift-R shrinks/grows Pd window
  Ctrl/Cmd-Shift-L clears Pd window's text console
  Ctrl/Cmd-B opens the Help Browser

• you can now use "~" in all paths to mean home folder, and on Windows you can use environment variables, lie %UserProfile% in paths

• improved Cut/Copy/Paste support for working in object and message boxes

• fixed Cut/Copy/Paste for the Pd window's console

• [declare] and [import] now sorted out for loading (but much work needs to be done before there namespace support is complete)

• "File -> Save As" defaults to the Home folder (~/) on Mac OSX

• new patches default to the folder last saved in

• included pgp_opengl aka 3dp on GNU/Linux and Mac OS X

• 'hardware' and 'deprecated' removed from libraries loaded by default

• On Debian/Ubuntu, the packages now install into /usr rather than /usr/local

• On Mac OS X, you can now build "standalone" applications from the File menu.

• bug fixes and clean up of [hid] and mapping externals

• included config in Info.plist for the Spotlight Importer

KNOWN BUGS

• check http://puredata.info/dev/bugtracker before reporting bugs

• Escape, Enter, and Ctrl/Cmd-W don't close the Path and Startup preferences

• pdp_opengl is alpha and will definitely crash Pd

• loading pdp_opengl will crash Pd if X11 is not open before trying to load it

• the GUI runs slower in some situations

trying to get arduino to work with my linux distro...

Checked /var/log/messages and it says:

kernel: usb 1-2: new full speed USB device using ohci_hcd and address 4
kernel: usb 1-2: configuration #1 chosen from 1 choice
kernel: usbcore: registered new driver usbserial
kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
kernel: usbcore: registered new driver usbserial_generic
kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core
kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
kernel: ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
kernel: drivers/usb/serial/ftdi_sio.c: Detected FT232BM
kernel: usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
kernel: usbcore: registered new driver ftdi_sio
kernel: drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver

All looks fine....

The problem seems to be that I can't select the serial port number using "Comport" inside the "Arduino" abstraction, tried giving it a file path using the devicename message /dev/usb/ttyUSB0 but no luck.

Any ideas?

...seriously (serialously?) this is doing my head in...

Hey,

thanks to everyone who responded to my posts both here and in the mailing list. Since then, I've figured out how to compile externals written in C using Microsoft Visual C++ 2005. There's more to document, however, such as how to compile externals using some of the other Windows compilers (Borland, djgpp, etc.), and also how to compile externals written in C++ in Windows. But one thing at a time.

one little thing to note... steps 4 and 7 may seem a little roundabout, but they account for the fact that MSVC sometimes has trouble with spaces in directory names (eg. C://Program Files/). If anyone knows how to override this behavior, post a reply, and I'll try to simplify the steps accordingly.

Updated June 29, 2007:
use [b]C://Progra~1/[/b] instead of [b]C://Program Files/[/b],
use [b]C://Docume~1/[/b] instead of [b]C://Documents and Settings/[/b], etc.

So, without further ado...

How to compile a pd external written in C using Microsoft Visual C++ 2005:

Compared to Windows, linux offers a much more user-friendly environment for compiling pd externals. However, with a little patience, a usable environment can be set up in Windows, and the good news is that everything you need is available for free. There are several reputable Windows-compatible C/C++ compilers out there, but here I'll discuss compiling externals with Microsoft Visual C++ 2005 (MSVC for short).

1. Download and Install Microsoft Visual C++ 2005 Express Edition.
a. Click the link above, then click Go! in the Visual C++ box.
b. Run vcsetup.exe to install the program
(the setup wizard should guide you through the process).

2. Download [url=http://download.microsoft.com/download/7/7/3/7737290f-98e8-45bf-9075-85cc6ae34bf1/VS80sp1-KB9267
]Visual C++ 2005 Express Service Pack 1.
a. Click the link above to download the Service Pack.
b. Run VS80sp1-KB926748-X86-INTL.exe to install the program.

3. Create a new project:
a. Open Visual C++.
b. Open the New Project window (Ctrl+Shift+N).
c. In the Project Types pane, select Visual C++.
d. In the Templates pane, select emptyproj.
e. Enter object name (helloworld).
f. Leave Create directory for solution unchecked, and click OK.

4. Import the pd header file:
a. Get m_pd.h here, or, using pd-vanilla (not pd-extended):
1. Open Windows Explorer or My Computer.
2. Navigate to the pd/src/ directory on your system.
3. Open m_pd.h in a text editor (file type is: C/C++ header).
b. Select all (Ctrl+A).
c. Copy selection to the clipboard (Ctrl+C).
d. Back in Visual C++, open the New File window (Ctrl+N).
e. In the Categories pane, select General.
f. In the Templates pane, select Text File, and click Open.
g. Copy the contents of m_pd.h into the editor window (Ctrl+V).
h. Open the Save File As Window (Ctrl+S).
i. Save as m_pd.h.
j. From the File Menu, select Move m_pd.h into; select helloworld.

5. Write the source code for the external in C.
a. Open the New File window (Ctrl+N).
b. In the Categories pane, select General.
c. In the Templates pane, select Text File, and click Open.
d. Write your source code in the editor window.

The following example is taken from the tutorial by Johannes M. Zmoelnig.

#include "m_pd.h"

static t_class *helloworld_class;

typedef struct _helloworld {
  t_object  x_obj;
} t_helloworld;

void helloworld_bang(t_helloworld *x)
{
  post("Hello world !!");
}

void *helloworld_new(void)
{
  t_helloworld *x = (t_helloworld *)pd_new(helloworld_class);

  return (void *)x;
}

void helloworld_setup(void) {
  helloworld_class = class_new(gensym("helloworld"),
        (t_newmethod)helloworld_new,
        0, sizeof(t_helloworld),
        CLASS_DEFAULT, 0);
  class_addbang(helloworld_class, helloworld_bang);
}

6. Save and import the source code into the project:
a. Open the Save File As Window (Ctrl+S).
b. Save as helloworld.c.
c. From the File Menu, select Move helloworld.c into; select helloworld.

7. Access the pd library file:
a. Open Windows Explorer or My Computer.
b. Navigate to the pd/bin/ directory on your system.
c. Right-click on pd.lib (file type is: Object File Library) and select Copy.
d. Navigate to the C://TEMP/ directory on your system.
e. Paste the copy of pd.lib in the C://TEMP/ directory (right-click or Ctrl-V).

8. Set configuration properties:
a. Set configuration type to .dll:
1. Back in Visual C++, open the helloworld Property Pages window (Alt+F7).
2. In the left pane, select Configuration Properties >> General.
3. In the right pane, under Project Defaults, click on
Configuration Type, and select Dynamic Library (.dll)
(using the arrow on the right).

b. Add MSW to preprocessor definitions:
1. In the left pane, select
Configuration Properties >> C/C++ >> Preprocessor.
2. In the right pane, type MSW in the Preprocessor Definitions field.

c. Tell compiler which language to use:
1. In the left pane, select
Configuration Properties >> C/C++ >> Advanced.
2. In the right pane, select Compile As.
3. Select Compile as C Code (/TC) by clicking the arrow on the right.

d. Tell linker where to find pd.lib:
1. In the left pane, select Configuration Properties >> Linker >> Input.
2. In the right pane, select Additional Dependencies and enter
C://TEMP/pd.lib.

e. Tell linker to export the setup function:
1. In the left pane, select
Configuration Properties >> Linker >> Command Line.
2. In the right pane, type
/export:helloworld_setup in the Additional options field.
3. Click OK.

9. Compile and link:
a. Use the Build Solution command (F7).

10. Copy the new helloworld.dll file into pd.
a. Open Windows Explorer or My Computer.
b. Navigate to the
My Documents/Visual Studio 2005/Projects/helloworld/Debug/
directory on your system.
c. Right-click on helloworld.dll (file type is: Application Extension)
and select Copy.
d. Navigate to the pd/extra directory on your system.
e. Paste the copy of helloworld.dll in the pd/extra directory
(right-click or Ctrl-V).

11. Test the external in pd.
a. the external should now be a useable object in pd.
b. open a new pd patch and try to create a helloworld object.
c. add a bang to the left inlet and test it out.
d. if the main pd console window displays "Hello world !!",
the external has succeeded.

Hope this helps!
-- middlepedal

SUBJECT: Need help with PD externals

Hi,

1. I have written some code in C/C++. I would now like to create a pd external and be able to run my C/C++ code in pd (windows environment). I would like my PD object to have say 3-4 inlets and 2-3 outlets.
   Furthermore at least one of the inlets would contain compound data, something like an array of 10-15 floats.
   Thus my external would be a bit more complex than the 'very basic one', which has a single float as inlet, & a single float as outlet.

2. I work in the windows environment (currently my operating environment has pentium machines with windows operating systems installed on them (windows XP, or windows 2000 Professional).
   I am using a the free DevCPP or DevC++ compiler (version 4.9.9.2) the IDE, (which uses the gnu C compiler MinGW at its base). Furthermore, I am using: Pd version 0.38.4-extended-RC8 (windows platform). I wonder if someone has already developed externals in a same (or similar, i.e. Windows) environment.

3. If someone has, can you please mail me a simple compilable code that you might have had prepared, and guide me through the exact steps which one must follow to make a pd external.

4. I wish to know, if in the Windows/DevCPP compiler environment, whether it is possbile to create a PD external without creating a dll in windows, or is it always necessary to first create a dll, even in the simplest case?

5. Last, but not the least, I must mention here that I don't have "a lot" of experience in pd, so I will appreciate if someone could explain things in an easy to understand style.
   But in any case, I will ask again, in case I don't understand something.
   I hope that should work.

Thanks and regards,

ps:

The following should actually have been posted as a separate thread, but since its related to the topic above, i continue to write it here:

In addition to what I have asked for above, I would also like some feedback on the following...

SUBJECT2: Creating/Compiling PD externals

My previous unsucessful attempts at creating/understanding the PD external:
I had tried to read through, and tried to implement the sample code in the tutorial, named:
"How to write an External for puredata" available at the iem site...

But I am facing a few problems, and here are some specific queries related to that:

A.) While in the windows environment, must one always need to create a dll first, or is it possible to create a PD external in any other way as well?

B.) If one must do it by first creating a dll, then the code as mentioned in the tutorial would need to be modified and can't just be copy+pasted & compiled directly. I.e.
One needs to paste the data declaration part in the header;
ii) Also one must declare all the subroutine (i.e. procedures/methods) names in the header file as well, while their definition or implementation goes in another main file, which must include our earlier created header file; and finally
iii) One must insert a special prefix before all the methods when are required for the dll...

Am I right about the 3 above mentioned points?

Thanks yet again,