[PD-dev] Midi overflow, when receiving Song Position Pointer (os x)

Max abonnements at revolwear.com
Thu Aug 1 21:41:56 CEST 2013


I'm trying to compile the git and i get an error in the make process:

ld: warning: directory not found for option '-L/sw/lib'
Undefined symbols for architecture x86_64:
  "_find_default_device", referenced from:
      _pm_init in libportmidi.a(pmmac.o)
     (maybe you meant: _pm_find_default_device)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [pd] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2



Am 07.07.2013 um 04:14 schrieb Miller Puckette <msp at ucsd.edu>:

> OK... maybe got it working now (should be in git repo).  THanks for flagging it.
> 
> M
> 
> On Fri, Jul 05, 2013 at 04:36:46PM -0700, Miller Puckette wrote:
>> Hmm... just looking at the code in s_midi_pm.c I can't understand how
>> it could ever have worked for sysex or 'system' messages.  I'll see if
>> I can get MIDI running on a MAC so I can try to fix it.
>> 
>> cheers
>> Miller
>> 
>> On Wed, Jun 05, 2013 at 01:59:45PM +0200, Jan Baumgart wrote:
>>> I've found the bad guy: it's the old version of the PortMidi
>>> Library, that's packaged with pd's source. After replacing it with a
>>> newer version (131) and recompiling, the midi overflow bug is gone.
>>> I couldn't get the latest version of portmidi compiled on os x
>>> 10.6.8 (probably a cmake issue).
>>> 
>>> Now that all midi messages are coming in, I've noticed that pd
>>> handles some midi system messages incorrectly. Seems like Pd
>>> assumes, that system messages always carry three data bytes (like
>>> sysex messages). But there are messages like Midi Time Code or Song
>>> Position Pointer, which have one or two data bytes.
>>> 
>>> cheers,
>>> Jan
>>> 
>>> 
>>> 
>>> On 3.6.13 17:07 , Jan Baumgart wrote:
>>>> Seems like [midirealtimein] is working under os x (although there's an
>>>> obsolete error "message midirealtimein: works under MSW only").
>>>> 
>>>> But when receiving a realtime messages (248, 250 or 252) [midiin] and
>>>> [notein] output 0.
>>>> Maybe this is related to the fifo overflow.
>>>> 
>>>> Correction: the status byte for the song position pointer is 242 (dec -
>>>> not hex)
>>>> 
>>>> On 3.6.13 15:18 , Jan Baumgart wrote:
>>>>> Hi there,
>>>>> 
>>>>> I'm experiencing a severe bug, when sending a Song Position Pointer
>>>>> message (0x242 0 0) to pd.
>>>>> 
>>>>> After sending just one SPP message to pd, the status window says:
>>>>> "warning: MIDI timing FIFO overflowed".
>>>>> 
>>>>> When looking at the output of [midiin] I see "242 0 0 0" repeated
>>>>> endlessly.
>>>>> 
>>>>> The Song Position Pointer message belongs to the System Common Messages
>>>>> and has two data bytes. Pd seems to get confused with this message.
>>>>> Where is the third data byte coming from?
>>>>> 
>>>>> I'm running precompiled vanilla pd-0.44-3 from puckette's site on 32-bit
>>>>> intel mac (os x 10.6.8).
>>>>> 
>>>>> 
>>>>> I have a related second question: Is there any way to receive midi
>>>>> realtime messages with pd on os x? I'm trying to receive Midi Beat
>>>>> Clock...
>>>>> 
>>>>> 
>>>>> cheers,
>>>>> Jan
>>> 
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>> 
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20130801/54986f50/attachment.pgp>


More information about the Pd-dev mailing list