"print" translates all characters in a message to their ASCII bytes. So, sending "print 0p100v" to [comport], will result in 48 112 49 48 48 118 sent to the Arduino. Check ASCII table to understand this in case you don't know ASCII.
Sending floating point values to control PWM doesn't really make much sense since PWM takes bytes, so integer values from 0 to 255. I don't know if "print" will actually break a floating point value and translate the dot as well (which is ASCII 46). If you want to send floating point values to the Arduino, you should make sure the dot gets translated to ASCII (if it's not done with "print" you should probably do it with [list fromsymbol]) and then in the Arduino code look for byte 46 and do the necessary math to assemble the floating point value.

First to @weightless and @ingox : thank you, for the great work on this.

Very cool! And I very much appreciate how promptly you solved the problem.

Am very sorry to say on the other hand, I did not state the problem as accurately and succinctly as I should have.

To the problem, as stated, the solution is perfect.

The problem, stated more directly (not doing the abstracting in the writing of the use-case (common pd-forum user-problem?)):

"I want to be able to add a slider to Mobmuplat (MMP) and have it self-center like a bend-wheel/tremolo-bar, and then send its resultant value over LAN as an OSC signal to my laptop with pd on it. And MMP is vanilla-only. (So no iem-guts.)"

Note: the wonderful, iOS app, "Syntien" (an OSC-gui design tool) has a property on its slider like this, "return to center". (Only handheld-app I have ever bought).

(I'll double check the above...) Yes. The above scenario is correct.

Seems such a control, would prove useful to not only me, but a wider audience. (Maybe?)

p.s. I approached the above problem by placing aerially-speaking "drag" on the slider, so incrementally it subtracted from the slider value then sent it back into the slider. The result was stack-overflows.

Any ideas on this front would be great.

Thanks, again, for the effort put into the solution of the original use-case.

Please, accept my apologies for not having been more forthcoming to begin with.

Sincerely,
Scott

Okay ;that's what I suspected you were doing. It is possible to use the MTP serial directly with linux and the mtpav driver, though this requires a machine with true hardware parallel port access (USB adapters won't cut it) and is limited to MIDI output only as the driver is a hack that was never finished. I used to run mine that way with a second USB MIDI interface connected to one or more of the MTP's unused routed MIDI outputs (there is, BTW still no way to connect the MTP USB version directly to a Linux system as it doesn't use a standard USB MIDI driver)

As far as the kernel is concerned, I've only ever used lowlatency or RT kernels for MIDI stuff. I don't know how a generic kernel would affect this problem but it's probably best avoided as they are not specifically built for multimedia.

Now read closely as this is where it becomes stupidly complicated.

First, make sure that the problem is internal to Pd. Your interfaces are probably not the issue (since Pd is only seeing the UM-1 driver I don't think the MTP even figures in here). However, the chosen MIDI API can get in the way, specifically in the case of the unfinished JACK MIDI. JACK MIDI presently can only pass SYSEX as short realtime messages. SYSEX data dumps will disappear if sent into the current JACK MIDI system. ALSA works OK. OSS probably too, but I have not tried it.

If that stuff is ruled out and you are still getting problems, it probably has to do with a set of longstanding bugs/oversights in the Pd MIDI stack that can affect the input, output, or both.

On the output side there is a sysex transmission bug which affects all versions of Pd Vanilla before 0.48. The patch that fixed Vanilla had already been applied to L20rk/PurrData for some time (years, I think). The output bug did not completely disable SYSEX output. What it did was to miss-format SYSEX in a way that can't be understood by most modern midi applications, including the standard USB MIDI driver software (SYSEX output from Pd is ignored and the driver/interface will not transmit anything). You would not notice this bug with a computer connected directly to an MTP because the MAC and Linux MTP drivers are programmed to pass raw unformatted MIDI.

If this is the problem and you have to use a pre-0.48 version of Vanilla it can be patched. See:

https://sourceforge.net/p/pure-data/bugs/1272/

On the MIDI input side of Pd we have 2 common problems. One is the (annoyingly unfinished but nevertheless implemented) input to output timestamping buffer that's supposed to provide sample-accurate MIDI at the output (if it was finished). This can be minimized with the proper startup flags (for a MIDI-only instance of Pd, -rt -noaudio -audiobuf 1 -sleepgrain 0.5 works for me) or completely defeated with a source code tweak to the s_midi.c file. This may not be the source of your particular problem as it usually only affects the time it takes to pass messages from input to output, but is worth mentioning as it can be very annoying regardless.

With SYSEX dumps it is more likely that the problem lies with the MIDI queue size. This is very common and I experienced it myself when trying to dump memory from a Korg Electribe Ea-1.. The current version of Pd limits the queue to a size of 512 (even worse it used to be 20) and any input larger than that will get truncated w/no error warning. There is not yet any way to change this with startup flags or user settings. This can only be "fixed" by a different tweak to s_midi.c and recompiling the app.

The attached text files are derived from the Pd-list and will show the specific mods that need to be made to s_midi.c.

pd_midi_io_timing_buffer_mod

pd_midi_input_quere_mod

Hello,
I've been making guitar effects with Puredata and Raspberry Pi.
Previously I did not care much about this problem, but at the last moment I got a terrible problem so I would like to consult with you.

I created Puredata Patches on Windows 10, copy Patches to Raspbian and use it.
In most cases there is no problem,
but depending on the Patches the sound reproducibility will be different.
Please help if there is a solution,thank you.

Windows_And_Raspbian.mp4
test.pd

*I uploaded same files in Google Drive and Dropbox.

Google Drive

Dropbox

1)There is a problem with the reproducibility of the sound, especially the problem is remarkable with the decay sound.
2)The problem is reproduced even if Windows 10 and Raspbian use the same USB Audio interface(Behringer UCG102)
3)Even if I use a different USB Audio interface (Zoom U - 22) in Raspbian, the problem is reproduced.

@NoDSP It all works fine on Windows. OSX I have not heard of problems since Pd addressed them in 2011. Ubuntu, some problems after 16.04 (and sometimes before... but X-window). Generally a lot of Linux font problems on Google.
Sorry I am not helping with your particular problem.
You could try a.... sudo apt-get install --reinstall x-ttcidfont-conf ttf-dejavu....... if not done so already.
I am having trouble understanding why it should be a tcl issue when it works fine on other Linux distros.
Tk 8.4 was a problem..... but it's very old now......
But Pd will need a re-write (again) just for newer Linux. I don't know what other problems that will throw up for system compatibility. There was a long debate about it last time.
David.

@johnwbyrd I have never looked at the source code, but I run a live performance with Pd....... 30 input channels, 8 out..... with live mixing and using [readsf~] for up to 15 minute backing tracks, and I have never had Pd hang even momentarily.
I use extended for that although I doubt the [readsf~] implementation is different.
However, I use windows7....... and is it possible that Pd and the OS treat disk access slightly differently on other systems? I doubt that.

[readsf~] requires an "open" and a "start"...... so it is not forward looking as it might be in an audio editor. However if you program the "open" in advance.... or even at load, then the start is instantaneous (in ram) and you can emulate an instant player.
If Pd is stumbling during playback..... look elsewhere for the problem....... not in [readsf~]......

A multi-GHz processor with rapid disc access should not have problems with audio or Pd...... they use a paltry fraction of the resources available.

Yes..... Pd prioritises audio..... like all programs that use audio.... over video, screen drawing...... everything. So if your patch is struggling in any way you could see the Pd gui stumble.
Check thoroughly your audio and latency settings.... any mismatch with the capabilities of the soundcard could cause what you are seeing.
More here about setting up your computer for audio......... https://forum.pdpatchrepo.info/topic/10125/audio-and-video-why-do-i-have-problems ..... with a link to a good read for problem solving!
You often just need to tell your OS to do as instructed......"and I mean it!"........... Otherwise it prefers to go and peruse it's Facebook page for likes!

Maybe, otherwise, use FL studio or something similar.
Programs written specifically for audio application will have been written in assembly language and be more appropriate for your purposes.
Communication with Pd is usually facilitated through at least midi or OSC messaging.
David.

Hello,

I created a new thread as the older post [Problem compiling on windows] (http://forum.pdpatchrepo.info/topic/967/problem-compiling-external-on-windows/16) seems to have ended and my problem has a different nature.
Moreover. I have not been able to find an answer on the puredata sites (puredata.info or puredata.org).

My problem:

My end goal is to play with the 'grid' external in pd-extended/externals/unauthorized/grid but since I do not get this one working and I have never compiled an external before I started with the simpler tutorials in Pd/doc/6.externs.

My steps and error are as follows:
**1. **Adap path in 'makefile' in Pd/doc/6.externs to 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC'
(this path contains a /lib folder with .lib and .obj files on my machine)
**2. **Start ( Admin) Visual C++ 2008 64-bit command prompt
**3. **Locate directory Pd/doc/6.externs
**4. ** run 'nmake pd_nt' command
**5. ** gives error in locating the libc.lib file
(LINK: fatal error LNK1181: cannot open input file 'C:...\VC\lib\libc.lib'

When I remove this instruction from the makefile, I does not find the kernel32.lib file also.
When I finally remove the former instruction, I get an error creating the library obj1,lib and object obj1,exp as I have 6 unresolved external symbols ex. obj1.ob : error LNK2019: unresolved external symbol __imp_post referenced in function obj1_float

Could someone help me solve these issues and help me succeed in making this external work?
Then, any additional explanation in getting grid to work afterwards?

Any additional info regarding Pd's treatment of externals/libraries etc is appreciated as well.. I just can't get a grip on it,

I would suggest using [list fromsymbol] or [moocow/any2bytes] to convert all the characters in your list to ascii values. Then you can split the list at 32 (which is the ascii value for a space) and sort them according to ascii values for a-z, which are 97-122. Take a look at [list-sort] and [list-split-at] in the list-abs library for ideas on how to do this.

Feel free to ask for more direction if I'm not being clear. You can see a full list of ascii characters here: https://upload.wikimedia.org/wikipedia/commons/thumb/1/1b/ASCII-Table-wide.svg/2000px-ASCII-Table-wide.svg.png

Hey,

Since today I have strange crashes on Windows 7 64bit.

Either pd.exe or pd.com crashes when executed.

I had Pd-extended 0.43.4 installed and it worked for days without problem. Today I've tried to load a .pd which I worked on at another computer (same version): pd.com crashed. I've tried to start Pd normal: pd.exe crashed.

I tried an uninstall and re-install, it's installing without problems, but doesn't create shortcuts.

I've tried running it as administrator, rebooted computer.

What's wrong here?!

"Problem details" by Windows:

Problem signature:
Problem Event Name: APPCRASH
Application Name: pd.exe
Application Version: 0.43.0.0
Application Timestamp: 5100f299
Fault Module Name: pd.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 5100f298
Exception Code: c0000005
Exception Offset: 0005300a
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1031
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

THE GOAL:

I want my Raspberry Pi 2 to automatically start up the Jack server with realtime scheduling, and subsequently start Pure Data with realtime scheduling, load a patch &c. without any user intervention from a login shell.

As a performance artist working primarily with psychodrama (the technology is definitely NOT the important part here), fiddling around at a terminal right before or during a performance is kind of... psychically inconvenient. I need a box that I can plug in, give the audio output to the sound guy, and be ready to go.

PREREQUISITES:

I use Raspbian with a Linux kernel compiled with realtime goodness. I have hand-compiled Jack2 and Pure Data with realtime support in order to take advantage of this. Running a process with realtime priority requires the proper PAM directives set in /etc/security/limits.conf and related places, but that is beyond the scope of this little write-up.

Also somewhat relevant: I use a M-Audio MobilePre USB soundcard (sounds pretty awful by today's standards, but it's an extremely USEFUL box and sounds good enough for the work I do). For full-duplex sound, this requires the RasPi's USB to be set to single speed. In this configuration, I can get just under 2.9ms latency with good CPU overhead for Pure Data to run a few of my 64-voice wavetable and delay line granulators. Yeah!

THE PROBLEM:

Purely by happenstance, I had given the jackd command in my startup script the option “-s” which allows the server to ignore overruns and so on. So things seemed to be working as expected, but I noticed a lot more glitches than when I manually started up Jack and Pd from the terminal without the “-s” option. Upon removing it from my startup script, everything failed! WAH.

So I started piping STDERR and STDOUT to text files so I could read what either Jack or Pd were complaining about. As it turns out, Jack was unable to start with realtime priority due to a permissions problem. (I assume this is one of the things the “-s” options allows jackd to ignore, and thus start up with non-realtime priority. Problem is that Pure Data can’t connect to a non-realtime Jack server when its “-rt” option specified.)

Now, I had already been through the whole rigamarole of setting proper memory and priority limits for the “audio” group, to which the user “pi” belongs. So I thought, okay, I have to execute these commands as “pi”, and while simulating a login shell because the security limits in question are only set during login.

So I did this:

su -l pi -c "/usr/local/bin/jackd -R -dalsa -dhw:1,0 -p128 -n3 -r44100 -S >> /home/pi/jackd.log 2>&1 &"

This says “login as user ‘pi’ and then run the jackd command with these options, piping the outputs to this log file and run it in the background”. Well, I still got all the same errors about not being able to set realtime priority. WHYYYYYYYYY?

THE SOLUTION:

I hunted and hunted and hunted on a Very Popular Search Engine til I decided to try searching “security limits not loaded with su -l” and found this.

(Makes me think of that Talking Heads lyric, “Isn’t it weird / Looks too obscure to me”.)

So by uncommenting the line # session required pam_limits.so in /etc/pam.d/su everything started working as expected.

CONCLUSION:

I now know a LOT MORE about PAM and how important it is to keep in mind when and in what order scripts and other little subsystems are executed; but also that sometimes the problem is EXTREMELY OBSCURE and is to be found in some seemingly far-flung config file.

I hope this helps anybody out there working with Pure Data and the RasPi. The second generation board really packs quite a punch and can run several hundred audio grains (run by vline~ and enveloped by vline~ and cos~) simultaneously without a problem. And I'm pretty sure this is just using ONE of the 4 cores!

I'm by no means an expert Linux sysadmin, so if you have any other suggestions or corrections, please let me know! I wouldn't have been able to get this far without all the generous and helpful writeups everybody else has contributed, both within the RasPi and Pure Data communities. If you have any questions about anything I glossed over here, I'll do my best to answer them.