Re: [PD] best format for send/receive between iOS and libPD

[Rich E]

I'd second what Miller said, for a different reason though: every time you
send a message from your app's main thread (the iOS / obj-c bits) into pd
(the libpd bits), a mutex will lock because the audio thread runs on a
different thread and needs to be synchronized.  Breaking the lists down
(not all the way down, just not one giant list) will mean that the
synchronization takes less time, so less chance of dropping audio packets.

Also, if you can, I'd store as much data as you can in pd arrays, and then
send across lookup information instead.  Pd arrays can also be filled from
the C side as well (look for PdBase copyArray*), but keep in mind this will
also require sync'ing, so you may have to watch how large the arrays are if
they are being filled while audio DSP is running.

cheers,
Rich


On Sat, May 3, 2014 at 12:15 PM, Billy Stiltner wrote:

> :)
>
>
> On Wed, Apr 30, 2014 at 5:57 AM, Miller Puckette  wrote:
>
>> Hi Matt -
>>
>> From Pd's perspective at least, it would be more efficient to handle the
>> messages separately (some of Pd's list operations have to copy the list,
>> which would be expensive if done iteratively over a long list).
>>
>> cheers
>> Miller
>>
>> On Wed, Apr 30, 2014 at 01:37:05PM +0900, i go bananas wrote:
>> > I've got a six voice synth, each with about 20 variable parameters, and
>> > then sequence data, etc... and all of this data is being stored by the
>> > objective C front-end of my app.
>> >
>> > can someone tell me, hopefully from experience, what the best format is
>> to
>> > send a lot of pattern data between obj C and libPD ???  should i package
>> > all the data as one huge list, or break it all into individual
>> variables,
>> > or is it ok to organize it into groups for ease of management.
>> >
>> > my plan was to send messages like this from obj C:
>> >
>> > to [r instr1_pattern_data] :  [vol 0.8, pan 0.5, pitch 0.75, param1 0.99
>> > ... etc]
>> >
>> > actually, i'm not the one doing the C coding, i'm, just doing the pd
>> side,
>> > but i have to prepare things on my end to make it flow as well as
>> possible.
>> > Overall, i think there about 1400 values that need to be passed for
>> every
>> > pattern, so it probably does need to be as well streamlined as possible.
>> >
>> > cheers for any help
>> >
>> > Matt
>>
>> > ___
>> > Pd-list@iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [OT] Multichannel output with presonus firepod on windows, how?

[Rich E]

Ah, I see there is a 'multiple devices' tab that I missed.  Also noticed
that if I specify the channel count to be 4 with the device that is
representing channels 1 and 2, I can still send to the third and fourth
inlets on [dac~] woah.

Apologies for the noise



On Mon, Mar 31, 2014 at 1:55 AM, Rich E  wrote:

> Hi all,
>
> I'm not too familiar with using dedicated audio interfaces on Windows, but
> I find myself trying to get more than two channels to output on Windows in
> Pd with a Presonus Firepod, and all it allows for is stereo. Instead of one
> device that has 10 ins and 10 outs, I get 5 devices that each have 2 ins
> and 2 and outs.  This is not what I need. On both mac and linux you're
> given a single device with the correct number of channels, but not on
> windows?
>
> Does anyone know how to achieve multichannel i/o on windows with a device
> like this?
>
> cheers,
> Rich
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] [OT] Multichannel output with presonus firepod on windows, how?

[Rich E]

Hi all,

I'm not too familiar with using dedicated audio interfaces on Windows, but
I find myself trying to get more than two channels to output on Windows in
Pd with a Presonus Firepod, and all it allows for is stereo. Instead of one
device that has 10 ins and 10 outs, I get 5 devices that each have 2 ins
and 2 and outs.  This is not what I need. On both mac and linux you're
given a single device with the correct number of channels, but not on
windows?

Does anyone know how to achieve multichannel i/o on windows with a device
like this?

cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Wed, Feb 26, 2014 at 5:03 PM, Ivica Bukvic  wrote:

> The reason why I believe combining all of these will not be feasible is
> because in one of my recent conversations with Miller (and Miller please
> correct me if I somehow misremember here) he expressed his belief any
> project that exceeds N lines of code which I believe in this case it was
> something like 1, it becomes unmaintainable and dies. Supposedly
> current pd codebase is at about 60 percent of that. That same code also
> lacks a lot of basic facilities like infinite undo and other core tools
> necessary for any kind of basic editing (given the nature of pd's structure
> it needs to exist inside the engine itself that is also responsible for
> stacking order). Features that have been added in pd-l2ork have added at
> least a couple of thousand lines of code with the externals and everything
> else obviously going well beyond that.
>

Refactoring usually *reduces* code length, but the key to staying in sync
with vanilla (and all projects that use it) is to refactor in small chunks,
keeping the modifications focused.

For instance, it seems like there are two main concerns floating around:

a) multiple instances of pd
b) separating GUI from core

There are other suggestions like platform-specific vectorization and
multi-threaded support, but if you try to do these at the same time, you
reduce the chance of ever getting the code back into vanilla.  They can be
taken on after.

IMO, the best thing to do going forward for a) would be to sync up with
Miller and what he netted out with last time this was discussed ( see
thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html).
It seemed like he was proposing to take a hefty chunk of the work on, or
maybe if he is confident in merely the approach, someone else can have a go
at it.

For b) it seems like no one really knows fully what is entailed, maybe it
is something that just needs to be tried as a throw away first, with say a
minimal GUI in something other than tk as proof of concept.

Corollary about multi-instances and multi-thread support: while I agree
thinking about them together can be useful, I think the former will only
make the latter easier to take on afterwards.  The smaller the changes, the
easier it is to verify backwards compatibilty, and to accept into vanilla.

As a result even if we prune the code and make a libpd which again implies
> Miller is okay with that (as in abandoning his version and building a new
> GUI app that interfaces with libpd)
>

I don't think anyone wants this, my understanding is that the goal is to
make it where libpd does even less, by first isolating pd-core and its
memory usage.

cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Wed, Feb 26, 2014 at 6:39 PM, Miller Puckette  wrote:

> HI all -
>
> My figure was 100K lines, not 10K.  PD's C code is at about 70K now, and
> the
> Tcl/TK code is 7K - so I am only adding expansions very carefully now.
>
> Another related idea with an absurdly arbitrary round number attached: the
> code is
> built to last 50 years.  It's now about 17 ywars in (1/3 of its intended
> lifetime.)
>
>
Wow, that is an incredible number, and if I live that long, would love to
see pd turn 50. :)
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

Hey lets keep on topic here. :) I'd say separating the gui and core is much
less work than trying to revamp pd's threading model.  Just *enabling*
thirdparty
GUI's that can talk to pd core as an audio and computation engine, should
be possible without breaking backwards compatibility.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes  wrote:

>  On 02/20/2014 09:50 PM, Rich E wrote:
>
>
>
> On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes wrote:
>
>>   On 02/18/2014 11:11 PM, Rich E wrote:
>>
>>
>>
>>
>> On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox  wrote:
>>
>>> Ah wait, duh. Of course the graph needs to know positioning, that's how
>>> it determines execution order or independent blocks of objects right?
>>>
>>>  On Jan 13, 2014, at 5:14 PM, Dan Wilcox  wrote:
>>>
>>> Does the dsp graph rely on positioning? I thought only via connections.
>>> I'd imagine the gui wrapper should only worry about positioning and simply
>>> update those changes when saving.
>>>
>>>
>>>
>>
>>  IMO a separation between GUI and core could/would include position,
>> e.g. objects have their connections mapped by an index, GUI assigns the
>> index to the object based on position.  This would allow for some much more
>> sophisticated GUI's, such as 3d, or even a more human-readable text version
>> (json has been mentioned).
>>
>>
>>  You run into problems when you want to get decent GUI interaction _and_
>> expect to deliver audio to the soundcard in realtime.
>>
>>
>  The GUI and audio shouldn't be updated from the same thread.  This is
> one nice thing about libpd, it forces a separation.
>
>
> What are the drawbacks to the multi-threaded approach?  Specifically, for
> a full-fledged editing environment where you can't easily predict what the
> userbase is going to come up with inside the GUI?
>
>
>
Firstly, I think the decision should at least be available (to process
audio and GUI on separate threads), since this is the most common way to
handle the two different update rates.  Especially since, with most GUI
frameworks, you _must_ update the GUI on the main / UI thread, which is
running at 60fps.

But to answer the question... drawback is having to manage the whole 'this
method must to be called on the audio thread, and that method must be
called on the non-audio thread'. However this turns out to be little of a
limitation since it is almost always what you want to do anyway, and you
gain huge amounts in the area of responsiveness.

In the end, every situation is different. With pd vanilla, audio is most
important and maybe that deserves the current architecture.  To me, it is
more about keeping options open, which is why I think abstracting the
visual position from the core is a good idea.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes wrote:

>  On 02/18/2014 11:11 PM, Rich E wrote:
>
>
>
>
> On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox  wrote:
>
>> Ah wait, duh. Of course the graph needs to know positioning, that's how
>> it determines execution order or independent blocks of objects right?
>>
>>  On Jan 13, 2014, at 5:14 PM, Dan Wilcox  wrote:
>>
>> Does the dsp graph rely on positioning? I thought only via connections.
>> I'd imagine the gui wrapper should only worry about positioning and simply
>> update those changes when saving.
>>
>>
>>
>
>  IMO a separation between GUI and core could/would include position, e.g.
> objects have their connections mapped by an index, GUI assigns the index to
> the object based on position.  This would allow for some much more
> sophisticated GUI's, such as 3d, or even a more human-readable text version
> (json has been mentioned).
>
>
> You run into problems when you want to get decent GUI interaction _and_
> expect to deliver audio to the soundcard in realtime.
>
>
The GUI and audio shouldn't be updated from the same thread.  This is one
nice thing about libpd, it forces a separation.

So in this type of world, the GUI can do whatever it needs to do in order
to draw at the desired framerate, and flags graph changes along the way.
 The changes are then converted into a GUI-agnostic format and
synchronously issued to the audio context.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd separating gui from core

[Rich E]

On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox  wrote:

> Ah wait, duh. Of course the graph needs to know positioning, that's how it
> determines execution order or independent blocks of objects right?
>
> On Jan 13, 2014, at 5:14 PM, Dan Wilcox  wrote:
>
> Does the dsp graph rely on positioning? I thought only via connections.
> I'd imagine the gui wrapper should only worry about positioning and simply
> update those changes when saving.
>
>
>

IMO a separation between GUI and core could/would include position, e.g.
objects have their connections mapped by an index, GUI assigns the index to
the object based on position.  This would allow for some much more
sophisticated GUI's, such as 3d, or even a more human-readable text version
(json has been mentioned).


cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Legal restrictions for apps

[Rich E]

AFAIK, [expr]/[expr~] are not built into any libpd produced binaries, nor
any other GPL/LGPL components.  The user has to opt into those by adding
them to their project.

So you should be good.



On Thu, Oct 3, 2013 at 11:30 AM, Dan Wilcox  wrote:

> If your using libpd, you can simple remove the pure-data/extra/expr~
> folder and com[ile it without expr.
>
> On Oct 3, 2013, at 10:58 PM, Tony Hillerson 
> wrote:
>
> Ok, great. That's helpful everyone, thank you.
>
> --
> Tony Hillerson
>
> On Wednesday, October 2, 2013 at 18:35 PM, Dan Wilcox wrote:
>
> My approach with PdParty so far is:
>
> - GPL source code is incompatible with the Apple App Store due to the
> static linking requirement which means you cannot distribute GPL libs as
> dynamic libs which can be updated or replaced by the user
>
> - GPL patches are fine, they are text files which are not compiled into
> your app binary so can be freely replaced, I expose all of the GPL patches
> I use to the user so they can modify or update them to satisfy the
> distribution requirement of the GPL
>
> - I leave out [expr] & [expr~] for now. The license in the expr src folder
> is LGPL, but the license in the source headers is GPL and the following is
> printed to console when first loading the external: "expr, expr~, fexpr~
> version 0.4 under GNU General Public License ". I will leave it out until
> those parts of the code are explicitly changed. If this has already
> happened, then we need to merge in those changes to libpd. So far, as
> Miller suggests, I've been replacing [expr] with regular math objects.
>
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Libpd running in OS X app

[Rich E]

Ah, that's right I forgot: using one AUHAL audio unit only works if you are
using the same device for input and output, otherwise you need to create
two as you found out. Unfortunately this is the default setup on a macbook,
but I found that it still works if you create an "Aggregate Device" in the
'Audio Midi Setup' preference pane (it'll also work with hardware sound I/O
interfaces).

Yea not sure how to leave those samples / what modifications to make to
PdAudioUnit - if you get something working that is fairly general maybe we
can work it in.

About the AUGraph, the limitation I ran into was trying to feed either
speech synthesis or AUFilePlayer output into pd from a render callback - I
could only get it to work with straight Audio Units and
AudioUnitSetProperty.  See here for the gory details:

http://lists.apple.com/archives/coreaudio-api/2013/Jan/msg9.html

cheers,
Rich


On Mon, Jul 8, 2013 at 6:20 AM, Joe White  wrote:

> Thanks for the link Rich!
>
> I had a look at your code and I could get the tone patch to work with
> input disabled, but enabling input caused an error:
>
> * *** ERROR *** -[PdAudioUnit
> initAudioUnitWithSampleRate:numberChannels:inputEnabled:][159] status code
> =  kAudioUnitErr_InvalidPropertyValue*
>
> I think this is due to the fact that with kAudioUnitSubType_HALOutput you
> need to set up two callbacks for input/output processing:
>
> *kAudioOutputUnitProperty_SetInputCallback* for retrieving the input
> samples by calling the AudioUnitRender() method, processing the samples and
> storing them into a ring buffer.
>
>  *kAudioUnitProperty_SetRenderCallback* for retrieving the samples stored
> in the ring buffer to output.
>
>
> I have a HAL Output Unit working with AUGraph in a controller class. I'll
> try and wrap it up this week and share it.
>
> However for this purpose I didn't need audio input so I opted for the
> Default Output unit. As you can see in the link from the previous email
> this simplifies the code A LOT :) Maybe it'd be useful to have two projects
> for output only and input/output. With the former being a very quick way
> for people new to libpd to get a project up and running.
>
> Regarding my issue with libpd not processing audio, as Dan pointed out, it
> *should *be working. However, thinking about it more it could be due to
> how I built the libpd library. I noticed Rich added the whole source code
> into his project so I'll try that and see if it makes any difference. Weird!
>
> Thanks for the help guys,
>
> Joe
>
> On 7 July 2013 03:02, Rich E  wrote:
>
>> I started adding support for using PdAudioUnit in a Cocoa / OS X app
>> (PdAudioController is too iOS-specific) and checked my progress into the
>> cocoa branch here:
>>
>> https://github.com/libpd/libpd/tree/cocoa
>>
>> There is a (very basic) working app at:
>>
>>
>> https://github.com/libpd/libpd/tree/cocoa/samples/cocoa_samples/CocoaPdBasic
>>
>> You can also find some experimentation I did with moving towards an
>> AUGraph design but, in the end, I found it much more restrictive than just
>> using Audio Units directly.  Apologies for not finding the time to finish
>> this, I've been working full-time on a different project for many months
>> now... but hopefully once that is done I will finish off those samples,
>> unless someone else already has.
>>
>> In essence, there were only a few things that needed to be modified. Off
>> the top of my head, they were:
>>
>> - switch the audio unit to kAudioUnitSubType_HALOutput
>> - enable an input audio device (required on OS X, not on iOS)
>> - fix some Obj-C syntax issues that are different on OS X (property
>> synthesis generation I believe)
>>
>> By the way, you can use the C++ wrapper quite readily with any other
>> existing audio framework that provides OS X support - I use it in cinder
>> apps and of course Dan provides ofxPd.  I know others who have used
>> portaudio or FMOD directly.
>>
>> cheers,
>> Rich
>>
>>
>> On Sat, Jul 6, 2013 at 9:04 AM, Dan Wilcox  wrote:
>>
>>> Sorry. I assumed you were using the existing Obj-C PdAudioUnit and
>>> PdAudioController classes included with libpd which were written mainly for
>>> iOS. We should get around to tweaking it so it works on OSX. Did you try it?
>>>
>>> In skimming your code, it looks like you're doing everything the
>>> PAudioUnit does, so I don't see any obvious problems.
>>>
>>>
>>> On Jul 6, 2013, at 8:52 AM, Joe White  wrote:
>>>
>>> Sorry that previous code had some test stu

Re: [PD] Libpd running in OS X app

[Rich E]

I started adding support for using PdAudioUnit in a Cocoa / OS X app
(PdAudioController is too iOS-specific) and checked my progress into the
cocoa branch here:

https://github.com/libpd/libpd/tree/cocoa

There is a (very basic) working app at:

https://github.com/libpd/libpd/tree/cocoa/samples/cocoa_samples/CocoaPdBasic

You can also find some experimentation I did with moving towards an AUGraph
design but, in the end, I found it much more restrictive than just using
Audio Units directly.  Apologies for not finding the time to finish this,
I've been working full-time on a different project for many months now...
but hopefully once that is done I will finish off those samples, unless
someone else already has.

In essence, there were only a few things that needed to be modified. Off
the top of my head, they were:

- switch the audio unit to kAudioUnitSubType_HALOutput
- enable an input audio device (required on OS X, not on iOS)
- fix some Obj-C syntax issues that are different on OS X (property
synthesis generation I believe)

By the way, you can use the C++ wrapper quite readily with any other
existing audio framework that provides OS X support - I use it in cinder
apps and of course Dan provides ofxPd.  I know others who have used
portaudio or FMOD directly.

cheers,
Rich


On Sat, Jul 6, 2013 at 9:04 AM, Dan Wilcox  wrote:

> Sorry. I assumed you were using the existing Obj-C PdAudioUnit and
> PdAudioController classes included with libpd which were written mainly for
> iOS. We should get around to tweaking it so it works on OSX. Did you try it?
>
> In skimming your code, it looks like you're doing everything the
> PAudioUnit does, so I don't see any obvious problems.
>
>
> On Jul 6, 2013, at 8:52 AM, Joe White  wrote:
>
> Sorry that previous code had some test stuff in it, here's a slightly
> cleaner version (ARC'd)
>
> http://pastebin.com/index/1bR2Ftqn
>
> On 6 July 2013 13:47, Joe White  wrote:
>
>> How do you mean the CoreAudio backend? I would have thought I should just
>> be able to call the process function in my render callback. Did you check
>> out the code I posted? I happy to provide that as an AudioController for
>> libpd on OSX. Messages and print objects work correctly but libpd is not
>> processing any audio.
>>
>> http://pastebin.com/1bR2Ftqn
>>
>> Cheers,
>> Joe
>>
>>
>> On 5 July 2013 23:33, Dan Wilcox  wrote:
>>
>>> As far as I know, the OSX port isn't finished and the CoreAudio backend
>>> isn't hooked up. Anyone wanna help out there or sponsor us? :D
>>>
>>> On Jul 5, 2013, at 7:56 AM, pd-list-requ...@iem.at wrote:
>>>
>>> *From: *Joe White 
>>>  *Subject: **[PD] Libpd running in OS X app*
>>> *Date: *July 5, 2013 7:34:47 AM EDT
>>> *To: *pd-list 
>>>
>>>
>>> Hi guys,
>>>
>>> Does anyone have any experience running libpd in an OS X app, using
>>> CoreAudio.
>>>
>>> I'm able to run a patch and receive print statements but I'm not getting
>>> any audio output and DSP doesn't seem to be processing. I created a quick
>>> test tone in code to see if it was my audio unit but that works. My main
>>> problem it seems is that after calling
>>>
>>>   [PdBase processFloatWithInputBuffer:leftBuffer outputBuffer:leftBuffer
>>>  ticks:ticks];
>>>
>>> ...the buffer is still empty. Anyone have any ideas?
>>>
>>> I'm calling [PdBase computeAudio:] just before I start the AudioUnit.
>>> Here's the whole controller class if that helps:
>>> http://pastebin.com/eYf1Facp
>>>
>>> Any help would be much appreciated!
>>>
>>> Many thanks,
>>>
>>> Joe
>>>
>>>
>>>  
>>> Dan Wilcox
>>> @danomatika
>>> danomatika.com
>>> robotcowboy.com
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Follow me on Twitter @diplojocus
>>
>
>
>
> --
> Follow me on Twitter @diplojocus
>
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [announce] [pd-fileutils] released, a command-line tool for managing pd files

[Rich E]

Yea this is really nice, glad you got the proof of concept working!

Is there a number box?  Couldn't find it.

Please keep us all posted..

On Fri, Mar 1, 2013 at 12:08 PM, Hans-Christoph Steiner wrote:

>
> Wow, that's impressive, it actually works!  Rough, yes, but working.
>
> .hc
>
> On Mar 1, 2013, at 10:34 AM, s p wrote:
>
> Actually I've had a crappy demo of patching in the browser running for
> quite a while now :
> http://funktion.fm/webpd/demos/simple-gui/simple-gui.html
>
> It works (not so well in Firefox, but in chromium it's fine).
>
> A friend of mine is developing a generic graph editor for dataflow
> programming, and I've been planning to migrate to this forever now, but
> didn't have the time ...
>
> 2013/2/28 Hans-Christoph Steiner 
>
>>
>> Very nice :)  I'd love to see full-on Pd patching in the browser :)
>>
>> .hc
>>
>> On 02/28/2013 02:02 AM, s p wrote:
>> > Sorry for the spam ... problems with gmail and html, the url is :
>> >
>> >  http://sebpiq.github.com/pd-fileutils/?gist=GISTID
>> >
>> >
>> > 2013/2/28 s p 
>> >
>> >> oops, ... I meant :
>> >>
>> >> "2) Go to this url (replace GISTID by your gist id) :
>> >> http://sebpiq.github.com/pd-fileutils/?gist=<
>> http://sebpiq.github.com/pd-fileutils/?gist=5054711>
>> >> GISTID"
>> >>
>> >> 2013/2/28 s p 
>> >>
>> >>> For example, here's one goodie brought by `pd-fileutils` :
>> >>>
>> >>> 1) Paste a patch to gist : https://gist.github.com/
>> >>> 2) Go to this url (replace  by your gist id) :
>> >>> http://sebpiq.github.com/pd-fileutils/?gist=<<
>> http://sebpiq.github.com/pd-fileutils/?gist=5054711>
>> >>> gistId>
>> >>>
>> >>> And your patch should be rendered to SVG. You can then send this link
>> to
>> >>> anybody to show your patch :)
>> >>>
>> >>> Of course for now the SVG rendering is super crappy, but I am working
>> on
>> >>> it, so it should be better very soon.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Sébastien
>> >>>
>> >>
>> >>
>> >
>> >
>> >
>> > ___
>> > Pd-list@iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>> >
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling externals for osx i5/i7

[Rich E]

Don't you want to compile universal binaries (-arch i386 -arch x86_64)?
 That way you only need one set.

On Sat, Nov 3, 2012 at 7:49 PM, Miller Puckette  wrote:

> This is strange... I thought i3/5/7 were upwards compatible with older
> processors and hence should not need any recompilation at all.  I hope
> there's some mistake... otherwise we'd need to make a whole new set of
> binaries for everything.
>
> Miller
>
> On Sat, Nov 03, 2012 at 10:47:10PM +0100, Orm Finnendahl wrote:
> > Hi list,
> >
> >  I just found out that some of my custom externals stopped working on
> > recent OSX (i5/i7) hardware (pd complains about arch mismatch).
> >
> > Since I don't own Apple gear I always compiled on a (virtual) OSX
> > machine on my linux box. I'd rather avoid having to update the
> > virtual box once again to a more recent OSX version, put the XCode
> > stuff on it and spend hours after hours just to get a compilation
> > environment.
> >
> > My questions:
> >
> > - is there any way to make gcc cross compile for OSX on linux?
> >
> > - is there an extension for i5/i7 and dual-core externals on OSX so
> >   that they can co-habitate with each other (similar to the .l_ia64
> >   and .l_i386 on linux)?
> >
> > - is a recompilation for linux i5/i7 hardware also necessary (and
> >   what's the extension for that)?
> >
> > Thanks for any hints,
> > Orm
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] AES Budapest

[Rich E]

For some spicy gulyas I would suggest the Sürcsarnok, near to the Great
Market Hall and the Szabadság Híd. :)  I may be spelling these things
wrong.. but it's well worth it and I were to pass through Budapest, that is
one place I wouldn't miss.

For music / night, Instant  is really nice and
unique, although music might not be as experimental as you'd like.
Electronic in the basement, folk upstairs.

Cheers,
Rich

On Tue, Apr 24, 2012 at 10:56 AM, Joson Android <
joson.andr...@googlemail.com> wrote:

> Hallo András
>
> thank you for you fast answers and hints.
> For clubs I would prefer some experimental music or art performance -stuff
> (like Pd..), or traditional hungarian music.
> For pubs i would prefer cheap beer and/or traditional hungarian food.
> First I look for a nice place to watch the soccer match BayernMünchen vs
> RealMadrid for my travel group..
>
> thanks again,
>
> Jonas
>
>
>
> On 24.04.2012, at 18:16, András Murányi wrote:
>
> > On Tue, Apr 24, 2012 at 17:37, Joson Android
> >  wrote:
> >> Dear List!
> >>
> >> I am going to AES-Convention to Budapest tomorrow. Are any of you
> attending? And do you know about any Pd related topics on the convention,
> and spaces or works to see in Budapest? Does any of you have a
> recommendation of Pubs or Parties till Saturday?
> >>
> >> Greetings from rainy Hamburg,
> >>
> >> Jonas
> >
> > Hello Jonas,
> >
> > the Calendar of Events is online and I don't see anything specifically
> > Pd-related. The Béla Bartók concert hall is a place to see/hear as it
> > has the best acoustics/technology in the country and may be one of the
> > best in the world.
> > For bars and clubs, you'll most likely have to cross the Danube, as
> > they are rare on the Buda side and frequent on the Pest side. I
> > recommend the inner parts of district VI and VII. Knowing your
> > pub/party taste I may be able to give you more exact tips.
> >
> > Greetings from rainy Budapest,
> >
> > András
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-dev] Filter design for iPhone

[Rich E]

What do you mean by break, crashes?  If yes, what version of libpd are you
using?  Up until about a month ago, floating point exceptions (such as NAN)
would crash libpd, whereas pd-vanilla ignores them.  Peter B. recently
added a commit that changed this:

https://github.com/libpd/libpd/commit/27c848a56d3d27e62231f8b0d9ef17c7c56cd9f9

Anywho, you'll probably want to take care of those NAN's anyway. :)  Not
sure why pd vanilla ignores SIGFPE.

cheers,
Rich

On Tue, Mar 20, 2012 at 4:57 PM, Ed Kelly  wrote:

> Hi,
>
> I'm trying to design or find a resonant lowpass filter for use with libPd
> for Openframeworks running on an iPhone 4.
>
> 1. I've tried the rjlib filter attached (filtertest_list.tar.gz) and it
> works fine in Pd, but instantly breaks when I run it on the iPhone - all
> other playing audio cuts out, and it is impossible to reset. I suspect that
> the buffers fb1 fb2 ff1 ff2 ff3 are hitting NAN values and staying there,
> but I haven't tested this.
>
> 2. I've had a go at implementing the filter from
> http://www.musicdsp.org/archive.php?classid=3#25 as a Pd external
> (mvcf~.tar.gz) and it is very efficient CPU-wise. However, higher values of
> f or q cause the internal filter buffers to hit NAN and stay there (tested
> in Pd - I haven't tried this on the iPhone yet).
>
> I would ideally like to find out why the second attempt breaks at high q
> and/or f, as what I want is a 24dB/Octave moog-ish filter. I'm sure those
> of you with higher math skills will intuitively know why, but I'm just
> learning calculus now (my early education was a bit chaotic). I'm also
> limited by the fact that this is for a commercial project (although I'll be
> happy to share the code :) so I can't just take a GPL external and
> recompiled libpd with it.
>
> Ed
>
> Gemnotes-0.1alpha: Live music notation for Pure Data
> http://sharktracks.co.uk/
>
> ___
> Pd-dev mailing list
> pd-...@iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] C++ for reusable dsp lib - or better use C?

[Rich E]

It's a bit dated now, but loris is a good example; a sophisticated sound
modeling library. Written in C++ with a procedural interface in C and a
scripting interface in python:

http://www.hakenaudio.com/Loris/#doc

cheers,
Rich

On Fri, Mar 2, 2012 at 11:32 PM, katja  wrote:

>
> Can anyone point me to an example of a C++ lib with C API, in the
> field of dsp? Not sure if I can think of the best way how to do it.
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] C++ for reusable dsp lib - or better use C?

[Rich E]

For the last 10 years or so, it's been considered bad practice to use naked
pointers in C++.  This is because of shared_ptr and friends, along with
stl.  It's great; for example, I have a moderately sized C++ project I'm
working on at the moment that has absolutely no explicit delete's -
everything is handled by scope.

Here's a recent talk from Bjarne Stroustrup who says something to these
affects:
http://video.ch9.ms/ch9/252f/ed5c3dc3-3335-493b-9e2c-9fd00012252f/GoingNative2012KeynoteStroustrup_med_ch9.mp4

I think he gets into unique_ptr about 2/3rds in.

On Sun, Mar 4, 2012 at 7:10 PM, Billy Stiltner wrote:

> You guys made me remember why I don't like compiler options. Thanks! haha.
> asm to me is like programming in c++. but inline assembly in either c or
> c++ is not. What we need is flat address space without the overhead of GDS
> segment sorcery. It's pretty bad to be able to delete a  list of a list of
> pointers to objects  that deletes itself before it deletes itself in a
> polymorphic virtual destructor. ;) C++ is great but it is much easier to
> keep up with pointers in c. c is just like c++ without the confusion you
> can work yourself into a pointer to a function is a pointer to a function
> and if yo look at the assembly language there aint nothing wrong with using
> struct instead of class. it's all code an data when its running. the
> differences in the output are going to be more than likely caused by leaky
> capacitors and noisy fans or  2 coils of wire too close together.
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] C++ for reusable dsp lib - or better use C?

[Rich E]

On Sat, Mar 3, 2012 at 3:47 AM, Hans-Christoph Steiner wrote:

>
> The C++ ABI compatibility problems are not the only thing that make C++
> hard to deploy.  On limited platforms like Android, they include limited
> C++ support, like no exceptions and other stuff.  Its still possible to
> write portable C++, if you track all of these various issues across the
> platforms you want to support.
>
>
Not true, the Android NDK added support for exceptions in R5, I think that
was about a year ago.  Here's a port of Cinder that works on android, which
uses just about every nifty feature available in C++ / stl / boost:

https://github.com/safetydank/Cinder/tree/android-refactor
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] latest Pd-Extended cpu usage (was: new editing features of Pd-extended 0.43, now in beta)

[Rich E]

Note that the issue I'm seeing is a difference in cpu usage between
Pd-Extended and Pd-vanilla.  In OS X 10.7, when opening up each version of
pd and looking at Activity Monitor (before every opening a patch or turning
on DSP), I get:

- Pd-0.43.1-extended-20120228 running at ~ 17% cpu
- Pd-0.43-1 running at ~ 7% cpu

I can file this on sourceforge if it would be easier to track there.

On Wed, Feb 29, 2012 at 8:56 PM, Jamie Bullock  wrote:

>
>
> On 28 Feb 2012, at 21:10, katja wrote:
>
> >
> >
> > On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock 
> wrote:
> >
> > Yup, I think this is related to the Portaudio driver. I reported it here:
> >
> >
> http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=55736&atid=478070
> >
> > I don't think it's Portaudio itself that's at fault, but rather the way
> it interfaces with Pd.
> >
> >
> > DspFuncLib is in:
> >
> >
>  
> /System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
> >
> > If you run command nm on the lib, you'll see a plethora of dsp functions
> like MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and
> whatnot. Functions in this lib are called when the internal soundcard is
> used. When using an external soundcard with Pd, DspFuncLib is not called
> and that makes the big difference in CPU load.
> >
> > AppleHDA and mach_kernel are Apple libs as well and together with
> DspFuncLib they are responsible for the crazy CPU load in the
> 'idle-but-dsp-on' case.
> >
> > PortAudio functions are apparently statically built into Pd and they
> consume very little CPU time.
> >
>
> It seems that you're right, so I've closed the bug (my apologies to
> PortAudio!).
>
> I guess the real 'fix' for this is that Pd now has a block size setting in
> Preferences. With a block size of 1024, using the PortAudio driver I get a
> CPU use of <2% with DSP on. Checking "use callbacks" also seems to reduce
> CPU. Here, I got a reduction of ~2% with that checked.
>
> Also, I'm not sure if this is an improvement in recent versions of OS X,
> but Pd now runs at only ~5% with DSP on using the PortAudio driver with a
> blocksize of 64. This is on a MacBook Air i7/1.8.
>
> best,
>
> Jamie
>
> --
> http://www.jamiebullock.com
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Mac OS X/PowerPC builds needed

[Rich E]

Does anyone use Power PC for audio work anymore?  Also, is there a 10.7
machine? The latter seems more in demand.

cheers,
Rich

On Mon, Feb 27, 2012 at 12:56 PM, Hans-Christoph Steiner wrote:

>
> So the Mac OS X PowerPC machine from the build farm has died.  The hard
> drive is intact, so all the data is there.  I also have much more limited
> time for maintaining the PdLab machines.  So I'm looking for someone to
> host the Mac OS X PowerPC builds.  It can be really any recent PowerPC Mac.
>  The old machine was a 300MHz G4.
>
> Can anyone take this on?  I'd hate to see Mac OS X/PowerPC dropped from
> the supported platforms since they are still quite capable machines.
>
> .hc
>
>
> 
>
> "We have nothing to fear from love and commitment." - New York Senator
> Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] C++ for reusable dsp lib - or better use C?

[Rich E]

(To throw in a different take). I definitely like C++ more for ease of
interface.  Templated math functions and overloaded operators are just too
nice, the code looks so much better (at a user level).

There are also plenty of audio languages written in C++ - SuperCollider,
ZenGarden (which is coincidentally a rewrite of pd-core in C++), and Faust
are the first three that come to mind.  For graphics, there is both
openFrameworks and Cinder, which each use very different features of the
language.

In the end, I think you should use the language with the features you wish
to use.  While you could build an OO language on top of C, it is
essentially a procedural language, so why bother when that is what C++ is
for?

- rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] new editing features of Pd-extended 0.43, now in beta!

[Rich E]

On Sun, Feb 19, 2012 at 4:20 AM, Hans-Christoph Steiner wrote:

>
> You're using the 64-bit Mac OS X version.  That won't be a full release in
> 0.43 since there are some issues porting things away from Carbon that won't
> be resolved in time.  The 64-bit version means you can address huge amounts
> of memory, but with 0.43 it means you will not have:
>
>
>
Ah, got it.  The i386 version works for me (I think the naming is a bit
weird though, since I'm in OS X 10.7, not 10.5.  It'd make more sense by
appending the architecture, not OS X version), including gem and all other
externals I tried so far (cpuload was missing, but that was already
reported).  The magic glass is really nifty!  Saves alot of otherwise
pointless number boxes.

One thing of concern however is the cpu usage when DSP is on and there are
no patches open - Pd-0.43.1-extended-20120220 reports ~ 17%
while Pd-0.43.1-vanilla reports 7%.  What could be the cause of that?

Cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] new editing features of Pd-extended 0.43, now in beta!

[Rich E]

Thanks Hans!

I just tried on OS X Lion and got the following errors upon startup:

>

/Applications/Pd-0.43.1-extended-20120217.app/Contents/Resources/Scripts/../extra/tclpd/tclpd.pd_darwin:
dlopen(/Applications/Pd-0.43.1-extended-20120217.app/Contents/Resources/Scripts/../extra/tclpd/tclpd.pd_darwin,
10): Symbol not found: _TclFreeObj
  Referenced from:
/Applications/Pd-0.43.1-extended-20120217.app/Contents/Resources/Scripts/../extra/tclpd/tclpd.pd_darwin
  Expected in: dynamic lookup

/Applications/Pd-0.43.1-extended-20120217.app/Contents/Resources/Scripts/../startup/tclpd:
can't load startup library'!

>

Pretty fast startup though. :)

Cheers,
Rich

On Sat, Feb 18, 2012 at 9:32 AM, Lorenzo Sutton wrote:

> Thank you! Great news installed it and playing with it. Very good.
>
> Lorenzo.
>
>
> On 17/02/2012 21:02, Hans-Christoph Steiner wrote:
>
>>
>> http://at.or.at/hans/blog/**2012/02/17/new-editing-**
>> feature-of-pd-extended-0-43-**now-in-beta/
>>
>> The Pd-extended 0.43 release has been brewing an extra long time, about
>> 18 months now, mostly because there are lots of big improvements, and we
>> wanted to make sure we got it right, so your patches all work, but the
>> improvements all shine. Its now solidly beta, so we’re looking for testers.
>> Download a nightly build to try here:
>>
>> http://autobuild.puredata.**info/auto-build/latest/
>>
>> First off, the pd-gui side of Pd has been re-written from scratch. When
>> you run Pd, you are actually running two programs: pd is the core engine
>> and pd-gui is the GUI. Since basically all computers now come with multiple
>> CPU cores, this means that pd-gui will usually run on a separate CPU core
>> than pd, so they don’t step on each other’s toes. pd can entirely take over
>> its own core. If you want to make your patch use more CPU cores, then check
>> out the [pd~] object introduced in the last release (0.42.5).
>>
>> pd still handles some of the GUI stuff, but we are working on splitting
>> that out for the 0.44 release. That is a big chunk of work but it will also
>> bring big gains. In particular, it means that it will be possible for
>> people to write their own GUIs for Pd, covering not just the display of the
>> patch, but also the editing, and everything else. You like OpenFrameworks,
>> python, iOS, JUCE, Qt, etc.? Write your own pd-gui using the toolkit of
>> your choice. That’s the idea at least. That will take a solid chunk of
>> work, so we are looking for people to join that effort.
>>
>> There are so many ideas for making a better editing experience in Pd,
>> this release makes big strides to address the editing experience. There are
>> new features like Magic Glass, Autotips, Autopatch and Perf Mode, all
>> available on the Edit menu.
>>
>> • Magic Glass let’s you magically see the messages as they pass through
>> the cords. Just turn it on and hover above a cord, and you’ll see the
>> messages as they go by. You can even look at signal/audio cords.
>>
>> • Autotips gives you tips about what an object does, what its inlet
>> expects, and what comes out of the outlets.
>>
>> • Autopatch mode automatically connects objects as you create them.
>>
>> • Perf Mode, is a mode for performance that makes it harder to
>> accidentally close windows that are part of your performance.
>>
>> The Pd Window is also majorly overhauled. First of all, its fast. Much
>> much faster than the old one. You can now print thousands of messages per
>> second to the Pd Window and still edit your patch. No more will an
>> accidental dump of info cause the GUI to freeze up (well, ok, maybe if you
>> send 10,000 messages/second but that is a way too many). There are also now
>> 5 levels of printing messages to the Pd Window: fatal, error, normal,
>> debug, all. If you are only interested in fatal errors, switch the Pd
>> Window to 0 – fatal, and you’ll only see the worst problems. You want to
>> see every single message to debug? Switch to 4 – all, and you’ll get the
>> whole firehose.
>>
>> There is also the new log library, which lets you easily send messages
>> for those different levels. And all messages logged with the objects from
>> the log library are clickable: when you Ctrl-Click or Cmd-click (Mac OS X)
>> on the line in the Pd Window, it’ll pop up the patch where the message came
>> from, and highlight the specific object that printed it. That even works
>> for many messages from other objects as well.
>>
>> The Pd Window also includes very basic level meters for monitoring the
>> input and output levels. And for those who want to play with the GUI in
>> realtime, you can type Tcl code in the Tcl entry field, and directly modify
>> and probe the running GUI.
>>
>> One thing that you can do now is customize the GUI using GUI plugins. You
>> can change all sorts of colors, some fonts, and many behaviors. 

Re: [PD] How to stop pd from reopening patches on startup in OS X?

[Rich E]

Ah right, its in ~/Library/Preferences/org.puredata.plist, under
NSRecentDocuments.  You would think it would be in ~/Library/Application
Support/Pd/*, as it isn't a preference at all.

Anyway, I delete that item and its two entries (which are patches) and they
still try to open, and again it crashes. Dunno.

On Mon, Oct 10, 2011 at 11:42 AM, Hans-Christoph Steiner wrote:

>
> I imagine they are probably stored in some kind of plist in
> ~/Library/Preferences.  But that's just a guess.
>
> .hc
>
> On Oct 9, 2011, at 8:17 PM, Rich E wrote:
>
> Theres a bug with the latest vanilla version of pd in OS X (at least 10.7,
> don't know about older versions) that causes pd to crash when trying to
> reopen patches from the last session.  It is filed here:
>
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=3396316&group_id=55736&atid=478070
>
> As a work around, I'm looking for a way to clear the list of patches to
> reopen, but I can't find where they are stored.  Does anyone know?
>
> Cheers,
> Rich
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
>
> 
>
> I have always wished for my computer to be as easy to use as my telephone;
> my wish has come true because I can no longer figure out how to use my
> telephone."  --Bjarne Stroustrup (creator of C++)
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] How to stop pd from reopening patches on startup in OS X?

[Rich E]

Theres a bug with the latest vanilla version of pd in OS X (at least 10.7,
don't know about older versions) that causes pd to crash when trying to
reopen patches from the last session.  It is filed here:

https://sourceforge.net/tracker/index.php?func=detail&aid=3396316&group_id=55736&atid=478070

As a work around, I'm looking for a way to clear the list of patches to
reopen, but I can't find where they are stored.  Does anyone know?

Cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD on iPhone

[Rich E]

Development in libpd is going strong, although still in alpha.  The iOS
layer is working great, although both the audio and message callback layers
are currently going through an overhaul to be more flexible. For an example
of an app using it in the app store, check out NodeBeat by Seth Sandler and
Justin Windle (http://nodebeat.com/)

Cheers,
Rich

On Mon, Oct 10, 2011 at 2:13 AM, Eldad Tsabary wrote:

> Hello
> Does anyone here have experience with getting PD to work on iPhone or
> Android (using libpd or something else?)
> Thanks
> Eldad
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling pd vanilla in OS X 10.7 Lion

[Rich E]

There is a conditional in the makefile(s): HAVE_MSGFMT = no

but po/Makefile is still trying to call msgfmt.  I think it is because
po/Makefile is still added to AC_CONFIG_FILES, but this is where my
investigation ends and I create a bug report. :)

https://sourceforge.net/tracker/?func=detail&aid=3415638&group_id=55736&atid=478070

Concerning gettext in OS X, I got a big warning when installing with
homebrew that OS X ships with GNU gettext (or BSD, can't remember which),
which is weird since homebrew is pretty modern.



On Tue, Sep 27, 2011 at 2:27 AM, Hans-Christoph Steiner wrote:

>
> Hmm, yes, it seems that Mac OS X does not include gettext, its the same on
> my 10.5 install.  You can use the old build system in src/configure.ac and
> get no translations or install gettext and use the new build system.  I
> suppose we need to add gettext detection to the new build system so it'll
> build without gettext.
>
> .hc
>
>
> On Sep 26, 2011, at 12:53 AM, Rich E wrote:
>
> Hi all,
>
> I compiled pd vanilla (Miller's git repo) in OS X 10.7 Lion yesterday and
> ran into (only) a couple hitches.
>
> It seems gettext is missing and this causes the linking to fail because it
> can't find the msgfmt tool. I got it and compiled pd by doing:
>
> sudo brew install --universal gettext
> sudo ln -s /usr/local/Cellar/gettext/0.18.1.1/bin/msgfmt/usr/local/bin/msgfmt
> ./configure CFLAGS="-arch i386" LDFLAGS="-arch i386"
> make
>
> I don't know much about the gettext tool, but am I wrong in thinking that
> it should surely be there and blame apple for messing up on a very common
> unix package?
>
> Cheers,
> Rich
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
>
>
> 
>
> "Free software means you control what your computer does. Non-free software
> means someone else controls that, and to some extent controls you." -
> Richard M. Stallman
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] compiling pd vanilla in OS X 10.7 Lion

[Rich E]

Hi all,

I compiled pd vanilla (Miller's git repo) in OS X 10.7 Lion yesterday and
ran into (only) a couple hitches.

It seems gettext is missing and this causes the linking to fail because it
can't find the msgfmt tool. I got it and compiled pd by doing:

sudo brew install --universal gettext
sudo ln -s /usr/local/Cellar/gettext/0.18.1.1/bin/msgfmt/usr/local/bin/msgfmt
./configure CFLAGS="-arch i386" LDFLAGS="-arch i386"
make

I don't know much about the gettext tool, but am I wrong in thinking that it
should surely be there and blame apple for messing up on a very common unix
package?

Cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] audio > 1.0 not clipping?

[Rich E]

Yep, on a macbook.

Right, it sounded like there was a limiter in there, although I had
remembered in linux that any signal > |1.0| gets horrible
clipping artefacts.

Thanks for the explanation. Cheers,
Rich

On Mon, Sep 12, 2011 at 4:50 AM, chris clepper  wrote:

> When using the internal speakers on a Macbook a limiter is put into the
> CoreAudio chain.  A 3rd party hardware driver won't have this though.
>
> Since Rich says he can hear harmonics the sine wave is being clipped so
> things are working as expected.
>
>
>
> On Sun, Sep 11, 2011 at 1:57 AM, Miller Puckette  wrote:
>
>> Hi all --
>>
>> I assume this is happening on a Macintosh -- on that platform, Pd sends
>> floating point straight to the Mac audio system.  Rumor has it that the
>> Mac might compress and/or equalize the signal on its way out, so who
>> knows what you're actually getting.  But anyway, (and probably contrary to
>> Pd's documentation) audio isn't automatically clipped on Pd's output on
>> Mac although it is on Linux and Windows whose audio systems are explicitly
>> fixed point (and probably not messed with by hte system).
>>
>> cheers
>> Miller
>>
>> On Sun, Sep 11, 2011 at 01:49:52AM -0400, Mathieu Bouchard wrote:
>> > On Sun, 11 Sep 2011, Rich E wrote:
>> >
>> > >Does anyone know why this doesn't clip?:
>> > >[osc~ 200]
>> > >|
>> > >[*~ 1.5]
>> > >|
>> > >[dac~]
>> > >
>> > >I'm trying this using pd 0.43 and the audio still sounds good
>> > >(although some extra harmonics can be heard), despite the phases
>> > >being in the range of [-1.5, 1.5]... ?
>> >
>> > No, you mean the amplitude is 1.5. You're not doing anything about
>> > the phase (and anyway, it's relative, so you can only hear phase
>> > difference, not phase).
>> >
>> > If you hear extra harmonics, then it has to be already clipping.
>> > What makes you think that it isn't ?
>> >
>> >  ___
>> > | Mathieu Bouchard  tél: +1.514.383.3801  Villeray, Montréal,
>> QC
>>
>> > ___
>> > Pd-list@iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] audio > 1.0 not clipping?

[Rich E]

Does anyone know why this doesn't clip?:

[osc~ 200]
|
[*~ 1.5]
|
[dac~]

I'm trying this using pd 0.43 and the audio still sounds good (although some
extra harmonics can be heard), despite the phases being in the range of
[-1.5, 1.5]... ?

Cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] is OOURA fft algorithm still used?

[Rich E]

So is it just in there so that you can compile it in if you feel like
changing the makefile, or why is d_fft_fftsg.c included in the source?

Miller, why not use OOURA instead of Maynard, now that we know it is faster
and more versatile? I could have sworn that about 1 year ago, pd was using
the OOURA algorithm.


On Tue, May 17, 2011 at 3:25 PM, Rich E  wrote:

> Hi all,
>
> Is the OOURA fft algorithm (d_fft_fftsg.c) ever used in pd? I can't really
> tell from the makefile (granted, I don't really know how to use the
> autotools system), but I cannot see the file ever compiled into pd during
> the make.
>
> I though that OOURA was the fastest and most flexible fft algorithm
> included in pd..
>
> cheers,
> Rich
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] is OOURA fft algorithm still used?

[Rich E]

Hi all,

Is the OOURA fft algorithm (d_fft_fftsg.c) ever used in pd? I can't really
tell from the makefile (granted, I don't really know how to use the
autotools system), but I cannot see the file ever compiled into pd during
the make.

I though that OOURA was the fastest and most flexible fft algorithm included
in pd..

cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] completion-plugin new version

[Rich E]

Ah I got it working from Miller's git repo, its nice!  I'm sure it will make
programming in pd much faster once I'm used to it.

Still, does anyone know how to update to tcl 8.5 when using a precompiled
binary version of pd?

Cheers,
Rich

On Sun, May 15, 2011 at 5:05 PM, Rich E  wrote:

> I'd love to try this out but I'm using Pd-Vanilla, and so tcl 8.4.  Whats
> the easiest way to get pd on OS X to look at my copy of tcl 8.5?  I
> installed it in /usr/local/bin via ActiveTcl... I was hoping not to have to
> compile for source but oh well.
>
> cheers,
> Rich
>
>
> On Sun, May 15, 2011 at 4:19 AM, João Pais wrote:
>
>> that's great. don't know if you want to, but I would suggest to copy
>> another useful max feature: when you click on a send or receive object (the
>> same for their audio versions), a pop-up comes up listing how many other
>> objects exist using the same variable, and by clicking in any of these
>> objects it takes you to the patch where they are.
>>
>> João
>>
>>  hi
>>>
>>> I rewrote autocompletion-plugin which is now called 'completion-plugin'.
>>>
>>> there are some cool new features:
>>>
>>> - new GUI (inspired from desire-data)
>>> - added an option file
>>> - auto-creation of completed objects (via Return key)
>>> - added a 'save_mode' so pd remembers keywords for send/receive/table,
>>> etc..
>>> - added a nearly-bash-completion mode
>>> - completions update as you type
>>> ...
>>>
>>> there is a video demo there:
>>> http://vimeo.com/23557543
>>>
>>> you can grab the code there:
>>> http://github.com/gusano/pd_stuffs/tree/master/gui-plugins/completion
>>>
>>> requirements:
>>> - pd-0.43
>>> - tcl8.5
>>>
>>> I could test it on linux and osx only.
>>>
>>> OSX note:
>>> there are some focus problems with tcl8.5 (x11), but not with tcl8.5
>>> built with aqua support.
>>>
>>> as usual, bug reports are welcome ;)
>>>
>>> cheers,
>>> _y
>>>
>>> ___
>>> Pd-announce mailing list
>>> pd-annou...@iem.at
>>> http://lists.puredata.info/listinfo/pd-announce
>>>
>>> ___
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>> --
>> Friedenstr. 58
>> 10249 Berlin (Deutschland)
>> Tel +49 30 42020091 | Mob +49 162 6843570
>> Studio +49 30 69509190
>> jmmmp...@googlemail.com | skype: jmmmpjmmmp
>>
>>
>> ___
>> Pd-announce mailing list
>> pd-annou...@iem.at
>> http://lists.puredata.info/listinfo/pd-announce
>>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] completion-plugin new version

[Rich E]

I'd love to try this out but I'm using Pd-Vanilla, and so tcl 8.4.  Whats
the easiest way to get pd on OS X to look at my copy of tcl 8.5?  I
installed it in /usr/local/bin via ActiveTcl... I was hoping not to have to
compile for source but oh well.

cheers,
Rich

On Sun, May 15, 2011 at 4:19 AM, João Pais  wrote:

> that's great. don't know if you want to, but I would suggest to copy
> another useful max feature: when you click on a send or receive object (the
> same for their audio versions), a pop-up comes up listing how many other
> objects exist using the same variable, and by clicking in any of these
> objects it takes you to the patch where they are.
>
> João
>
>  hi
>>
>> I rewrote autocompletion-plugin which is now called 'completion-plugin'.
>>
>> there are some cool new features:
>>
>> - new GUI (inspired from desire-data)
>> - added an option file
>> - auto-creation of completed objects (via Return key)
>> - added a 'save_mode' so pd remembers keywords for send/receive/table,
>> etc..
>> - added a nearly-bash-completion mode
>> - completions update as you type
>> ...
>>
>> there is a video demo there:
>> http://vimeo.com/23557543
>>
>> you can grab the code there:
>> http://github.com/gusano/pd_stuffs/tree/master/gui-plugins/completion
>>
>> requirements:
>> - pd-0.43
>> - tcl8.5
>>
>> I could test it on linux and osx only.
>>
>> OSX note:
>> there are some focus problems with tcl8.5 (x11), but not with tcl8.5 built
>> with aqua support.
>>
>> as usual, bug reports are welcome ;)
>>
>> cheers,
>> _y
>>
>> ___
>> Pd-announce mailing list
>> pd-annou...@iem.at
>> http://lists.puredata.info/listinfo/pd-announce
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> --
> Friedenstr. 58
> 10249 Berlin (Deutschland)
> Tel +49 30 42020091 | Mob +49 162 6843570
> Studio +49 30 69509190
> jmmmp...@googlemail.com | skype: jmmmpjmmmp
>
>
> ___
> Pd-announce mailing list
> pd-annou...@iem.at
> http://lists.puredata.info/listinfo/pd-announce
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Dynamic patching with audio - review

[Rich E]

Thanks for the insight into more pd internals, although I think I prefer an
approach that does not heavily rely on public pointers floating around, like
pd_newest (it is funny that it is declared in m_pd.h, but then there is a
comment above its implementation that it is a hack, maybe be removed or
redesigned). I chose to use glob_evalfile because it is the closest method I
can find to opening a patch in the 'normal' way.  By the way, if I call
pd_newest after glob_evalfile(), will it give me a reference to the patch?
 I'd try it out, but I don't have my dev machine at the moment.

About namecanvas, there were two issues that I found when I had a system for
dynamically loading/unloading and linking together patches that contained
audio:

1) DSP had to be shut off and then turned back on once the linking was done.
 Sometimes I wouldn't even get audio out of an object until this happened.

2) closing a patch that had audio receivers containing $ variables via the
menuclose message was unstable, and would sometimes crash pd.

I didn't ever get to the bottom of these issues, but from what I understand,
[namecanvas] doesn't handle deallocation too well.  I lost all this code
anyway, so the new approach I am using for patch maintainence is through
libpd and an object oriented language (objective C at the moment, although I
think I would prefer python for running pd on a laptop/desktop).  It is just
really nice.

Cheers,
Rich

On Mon, Mar 21, 2011 at 8:30 AM, Mathieu Bouchard wrote:

> On Sun, 20 Mar 2011, Rich E wrote:
>
>  Dynamic patch loading/unloading (not dynamic patching) could also be done
>> directly in a pd external, provided the following small patch is accepted (:
>>
>> http://sourceforge.net/tracker/?func=detail&aid=3189135&group_id=55736&atid=478072
>>
>
> In the meanwhile, a simple workaround is to access the canvas_list global
> variable and walk the linked list of canvases to figure out what has been
> added. Sounds like a hack but is much faster than instantiating an object
> from the linked-list of at least two hundred or thousand names in
> pd_objectmaker.
>
> Besides, loading a patch with glob_evalfile is not the only way to load a
> patch. You can also load it through pd_objectmaker by pretending that it is
> an abstraction. Then you pick up the pointer using pd_newest(). In that
> case, however, don't bother looking in canvas_list, it's not there.
>
> Once you have a canvas pointer, you can find the $0 easily. It involves
> using a private interface that you can have by copying a struct definition
> from pd's source code in the same manner that several externals already use.
> Right after that, ce_dollarzero is yours.
>
>
>  Lastly, the $0 value that libpd recovers lets you send signals or messages
>> to a unique patch, without the need of [namecanvas] - a method that causes a
>> bag full of problems in itself when it comes to dynamic patch
>> loading/unloading.
>>
>
> I'm not sure I understand. What are the problems with [namecanvas] ?
>
>  ___
> | Mathieu Bouchard  tél: +1.514.383.3801  Villeray, Montréal, QC
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Dynamic patching with audio - review

[Rich E]

>
>
> Oh, cool, I wasn't aware of that. Can you tell a bit more about the
> performance
> of this approach and how it compares to dynamic patching for dynamic
> instantiation
> of objects/patches?
>
>  Ciao

> --
>  Frank BarknechtDo You RjDj.me?  _ __footils.org__
>
>
Initial performance is a little faster, as it doesn't take about 1,000 pd
objects to open the patch, just a call to glob_evalfile (through whatever
wrapper you are using to interface libpd), but that wasn't the main concern.
 The biggest bonus for me is that you can instantiate the patches in an
object-orientated manner (and in an object orientate language like python,
java, obj-c, c++, etc), on the fly.  Doing this with dynamic patching
involved using workarounds (like deleting to contents of a subpatch in order
to just delete an embedded patch) which seemed awkward and bug prone.
 Lastly, the $0 value that libpd recovers lets you send signals or messages
to a unique patch, without the need of [namecanvas] - a method that causes a
bag full of problems in itself when it comes to dynamic patch
loading/unloading.

Dynamic patch loading/unloading (not dynamic patching) could also be done
directly in a pd external, provided the following small patch is accepted (:
http://sourceforge.net/tracker/?func=detail&aid=3189135&group_id=55736&atid=478072

Cheers,
Rich

___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Dynamic patching with audio - review

[Rich E]

See this thread at Pd Everywhere:

http://noisepages.com/groups/pd-everywhere/forum/topic/new-patch-handling-api/

On Thu, Mar 17, 2011 at 1:17 AM, Rich E  wrote:
> Hi,
>
>
>> libpd will make a complete instance of Pd available inside of another
>> application, but it does not deal with instantiating single objects.
>
> libpd does (handle instantiating patches) as of about 2 weeks ago.  It
> maintains the $0 value of the patch as well, so you can send values to
> unique receivers.  You can make as many instances of a patch as you
> want and control them all separately, on the fly.
>
>> This is
>> still only possible with the "usual" mechanism Pd offers, i.e. dynamic
>> patching, and it has the same disadvantages.
>>
>> Maybe LuaAV would be worth a look, too?
>>
>> Ciao
>> --
>>  Frank Barknecht            Do You RjDj.me?          _ __footils.org__
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
>>
>

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Dynamic patching with audio - review

[Rich E]

Hi,


> libpd will make a complete instance of Pd available inside of another
> application, but it does not deal with instantiating single objects.

libpd does (handle instantiating patches) as of about 2 weeks ago.  It
maintains the $0 value of the patch as well, so you can send values to
unique receivers.  You can make as many instances of a patch as you
want and control them all separately, on the fly.

> This is
> still only possible with the "usual" mechanism Pd offers, i.e. dynamic
> patching, and it has the same disadvantages.
>
> Maybe LuaAV would be worth a look, too?
>
> Ciao
> --
>  Frank Barknecht            Do You RjDj.me?          _ __footils.org__
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] where to find $ args

[Rich E]

On Sat, Feb 5, 2011 at 3:44 PM, Mathieu Bouchard  wrote:

> On Tue, 25 Jan 2011, Rich E wrote:
>
>  Ah, understood.  Thanks for the nice code explanation and references...
>> they both really help.
>> I noticed that t_canvasenvironment remains privately defined, so it's
>> difficult to use this struct.  To get the dollarzero, I saw this works:
>>
>> canvas_setcurrent(x_canvas);
>> int dzero = canvas_getdollarzero();
>>
>
> That's an alias of pd_pushsym.
> You are supposed to use it with canvas_unsetcurrent (alias of pd_popsym),
> though I don't remember what can really go wrong if you don't unset/pop.
>
>
Lots of stuff goes wrong if you don't call canvas_unsetcurrent after setting
it. :) I know because I was running into all sorts of EXC_BAD_ACCESS signals
before doing it - specifically in some experiments in opening patches via
x_canvas points. Thanks for the tip, Mathieu.  I actually got a couple other
questions now that I have figured out a bit more, but I'll save it for
another thread..

Cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] where to find $ args

[Rich E]

Ah, understood.  Thanks for the nice code explanation and references... they
both really help.

I noticed that t_canvasenvironment remains privately defined, so it's
difficult to use this struct.  To get the dollarzero, I saw this works:

   canvas_setcurrent(x_canvas);

int dzero = canvas_getdollarzero();

Cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] where to find $ args

[Rich E]

Hi list,

If I were to make an external that has access to $ arguments, does anyone
know where I can find the necessary methods for retrieving this information?
 Or is it only available at instantiation?

Most importantly, I am looking for a way to get the $0 value of a patch from
C.

Cheers,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] libpd: An embeddable sound engine for Android, iOS, C, Java, and more

[Rich E]

Awesome work!

May I ask what the current issues are with iOS?

Rich

On Sun, Oct 24, 2010 at 4:11 AM, Tedb0t  wrote:

> Awesome!!
>
> > Chris McCormick (who has
> > also added the ability to make HTML5 web interfaces)
>
> Is there more information about this anywhere yet?  :D
>
> —t3db0t
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] build zexy i386 on snow leopard

[Rich E]

Great! I had forgotten to load hexloader as a library.

Any reason why it isn't loaded by default in pd extended?  I just added
hexloader to the startup flags and the zexy objects load fine.

Rich

On Thu, Mar 25, 2010 at 3:30 PM, Hans-Christoph Steiner wrote:

>
> I think you can do this, and then they'll work:
>
> [import hexloader]
>
> .hc
>
>
> On Mar 24, 2010, at 9:13 PM, Rich E wrote:
>
>  Anyone know how to do this? I want to get the library so >~, <~ etc. work
>> along with pd-extended.  This is how I got them before.
>>
>> I tried:
>>
>> make CFLAGS="-arch i386" LDFLAGS="-arch i386"
>>
>> but ld is complaining still.
>>
>> thanks..
>>
>> Rich
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>
>
> 
>
> All information should be free.  - the hacker ethic
>
>
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] build zexy i386 on snow leopard

[Rich E]

Anyone know how to do this? I want to get the library so >~, <~ etc. work
along with pd-extended.  This is how I got them before.

I tried:

make CFLAGS="-arch i386" LDFLAGS="-arch i386"

but ld is complaining still.

thanks..

Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-gui-rewrite preferences

[Rich E]

Well, I wanted to take this on if others thought it was a good idea, but my
laptop was just stolen from my flat (brand new Macbook Pro!).. arg.
 Hopefully I can scrape together a linux pc or something soon.  If so, I´ll
chime back in on this thread for suggestions.

rich

2010/1/22 Hans-Christoph Steiner 

>
> On Jan 22, 2010, at 1:12 PM, András Murányi wrote:
>
> Rich E wrote:
> > Hi list,
> >
> > I was just thinking, as I noticed that Hans made it where Apple+, opens
> the
> > preferences menu on OS X (as does every other native-mac app), why not
> group
> > all the preferences in one dialog, with sub dialogs?  This is how other
> apps
> > I use on OS X behave and I find it convenient.  Besides, if you save the
> > settings, all of the settings get dumped to the preferences file, no?
>  Why
> > not have them all in the same dialog, openable by a hotkey.
>
> On Fri, Jan 22, 2010 at 4:14 AM, Hans-Christoph Steiner wrote:
>
>>
>> The only reason its not like that is because someone hasn't done the
>> work.  I'd love to be able to include that work in pd-gui-rewrite.  Be
>> aware, it'll probably require some weirdness, because of the nature of
>> the messages that the pref panels send to 'pd'.  But I don't think it
>> would be too hard.
>>
>> One downside is that it you couldn't use Tcl/Tk 8.5 if you want it to be
>> included in Pd-vanilla.  But I am planning on switching Pd-extended 0.43
>> to Tcl/Tk 8.5 and above, since 8.5 adds a lot of very useful GUI stuff.
>>
>> .hc
>>
>>
> Let me think a bit forward on this... when you say a dialog and sub
> dialogs, do you mean a dialog with multiple tabs (that is what i see to be
> popular in practice) or literally many modals available from one central
> modal?
> I'd say tabs make the most sense, but i see that some of the dialogs are
> produced by the C
> side not Tcl/Tk (are they?) in which case it will not be easy to stuff them
> into the tabs.
> I'm asking because i would be willing to code this up.
>
>
> In 0.43, the prefs dialogs are split out into separate Tcl files:
> dialog_audio.tcl
> dialog_midi.tcl
> dialog_path.tcl
> dialog_startup.tcl
>
> I think each in its own tab makes a lot of sense.
>
> .hc
>
>
>
> 
>
> Access to computers should be unlimited and total.  - the hacker ethic
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-gui-rewrite testing

[Rich E]

Does this wish shell in Contents/MacOS have the Tcl/Tk Frameworks built into
it (whether Carbon or Cocoa)?

Its working now, thanks.  Nice method, I have one symlinked to the svn
repository and one for myself to hack on.

cheers,
Rich

On Sun, Jan 17, 2010 at 9:05 PM, Hans-Christoph Steiner wrote:

>
> On Jan 17, 2010, at 3:01 PM, Rich E wrote:
>
>
>
> On Sun, Jan 17, 2010 at 8:07 PM, Hans-Christoph Steiner wrote:
>
>>
>> On Jan 17, 2010, at 10:10 AM, Rich E wrote:
>>
>>
>>
>> On Sun, Jan 10, 2010 at 12:29 AM, Hans-Christoph Steiner 
>> wrote:
>>
>>>
>>> On Jan 9, 2010, at 5:37 PM, Rich E wrote:
>>>
>>>
>>> Still in OS X 10.6.  I don't have one of these problems with
>>> Pd-devel-0.43 (dec 15) nightly build, so it must all be because of the
>>> tk/cocoa version that you mention.  I'm not sure how to report it a tcl
>>> mailing list, as I don't know where the code is that implements these
>>> things.
>>>
>>> Does it make sense that the arrow keys are detected differently in
>>> Tk/Cocoa, so they are just sent to pd's gui C code as spaces?
>>>
>>>
>>> Not to me... it should be the same, that's why its worth reporting to
>>> tcl-mac.  You don't need to know the exact code that's causing the problem.
>>>  I read that list too, so I can fill in the details.  I just don't have
>>> access to a 10.6 machine these days.
>>>
>>> As for the text color issue in the audio settings, you'll have to point
>>> me towards what is controlling that.  I'll send you a screenshot after this
>>> email.
>>>
>>>
>>> Check out dialog_audio.tcl.  Its still mostly the original code, so it
>>> can be scary. ;)
>>>
>>> Do you know how I can force configure to use Tcl/Tk 8.5.7/Carbon?
>>>
>>>
>>> If you put a version of Tcl/Tk 8.5.7/Carbon frameworks into
>>> /Library/Frameworks, it should use them over the build in ones.  But that
>>> means using the Makefile in packages/darwin_app and running "make install".
>>>  For development, I just rename a nighly build as "Pd-devel.app" then inside
>>> the package, remove some guts and symlink it to my pd-gui-rewrite/0.43
>>> sources:
>>>
>>> h...@palatschinken.at.or.at:src > ls -l
>>> /Applications/Pd-devel.app/Contents/Resources/
>>> total 152
>>> lrwxr-xr-x   1 hans staff 3 2010-01-05 14:27 Scripts -> bin/
>>> -r--r--r--   1 hans staff 47204 2008-08-14 20:03 VolumeIcon.icns
>>> -r--r--r--   1 hans staff   545 2008-07-21 13:53 Wish.rsrc
>>> lrwxr-xr-x   1 root staff59 2010-01-05 14:32 bin ->
>>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/src/
>>> dr-xr-xr-x  13 hans staff   442 2009-12-15 08:41 doc/
>>> dr-xr-xr-x 180 hans staff  6120 2009-12-15 08:52 extra/
>>> dr-xr-xr-x   6 hans staff   204 2009-12-15 08:41 include/
>>> -r--r--r--   1 hans staff 42741 2008-02-14 18:14 pd-file.icns
>>> -r--r--r--   1 hans staff 37100 2008-02-14 18:14 pd.icns
>>> lrwxr-xr-x   1 root staff58 2010-01-05 14:31 po ->
>>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/po/
>>> dr-xr-xr-x   3 hans staff   102 2009-12-15 08:41 share/
>>> lrwxr-xr-x   1 root staff63 2010-01-05 14:31 startup ->
>>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/startup/
>>>
>>>
>> I like this way of running the newest sources from within the app bundle,
>> but I can't get it working yet.  I had to replace the executable in
>> Contents/MacOS, but then it cannot find pd-gui.tcl (I removed the bin folder
>> in the Resources directory and symlinked it to the pd-gui-rewrite/src/, like
>> you did).
>>
>> rich
>>
>>
>>
>> Literally all I did was:
>>
>> - download nightly Pd-devel build
>> - cd /path/to/Pd-devel.app/Contents/Resources
>> - rm -rf bin
>> - ln -s /path/to/pd-gui-rewrite/0.43/src bin
>> - ln -s /path/to/pd-gui-rewrite/0.43/po
>> - ln -s /path/to/pd-gui-rewrite/0.43/startup
>>
>> .hc
>>
>>
>>
> Really.  I do this and the executable in the Contents/MacOS folder is still
> run and not the one in the symlinked directory.  Oh well.
>
>
> Ah, ok, I understand now.  The exe in Contents/MacOS is not Pd but the Wish
> Shell, so you want it to run that.  'pd' resides in
> Contents/Resources/bin/pd.  Pd is two processes: 'pd-gui' (i.e. Wish) and
> '

[PD] pd-gui-rewrite preferences

[Rich E]

Hi list,

I was just thinking, as I noticed that Hans made it where Apple+, opens the
preferences menu on OS X (as does every other native-mac app), why not group
all the preferences in one dialog, with sub dialogs?  This is how other apps
I use on OS X behave and I find it convenient.  Besides, if you save the
settings, all of the settings get dumped to the preferences file, no?  Why
not have them all in the same dialog, openable by a hotkey.

- rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pd using 25% cpu when opened

[Rich E]

I just noticed that when I open pd, without a patch and with default
settings, it uses 25% cpu according to the Activity Monitor.  If I turn on
dsp then turn it back off, it drops to almost nothing.

I'm running OS X Snow Leopard 10.6.  I first noticed this using the 0.43
devel branch, but then experienced the same thing using the 0.42-5 dmg from
Miller's website.  Anyone else experiencing this?

rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-gui-rewrite testing

[Rich E]

On Sun, Jan 17, 2010 at 8:07 PM, Hans-Christoph Steiner wrote:

>
> On Jan 17, 2010, at 10:10 AM, Rich E wrote:
>
>
>
> On Sun, Jan 10, 2010 at 12:29 AM, Hans-Christoph Steiner wrote:
>
>>
>> On Jan 9, 2010, at 5:37 PM, Rich E wrote:
>>
>>
>> Still in OS X 10.6.  I don't have one of these problems with Pd-devel-0.43
>> (dec 15) nightly build, so it must all be because of the tk/cocoa version
>> that you mention.  I'm not sure how to report it a tcl mailing list, as I
>> don't know where the code is that implements these things.
>>
>> Does it make sense that the arrow keys are detected differently in
>> Tk/Cocoa, so they are just sent to pd's gui C code as spaces?
>>
>>
>> Not to me... it should be the same, that's why its worth reporting to
>> tcl-mac.  You don't need to know the exact code that's causing the problem.
>>  I read that list too, so I can fill in the details.  I just don't have
>> access to a 10.6 machine these days.
>>
>> As for the text color issue in the audio settings, you'll have to point me
>> towards what is controlling that.  I'll send you a screenshot after this
>> email.
>>
>>
>> Check out dialog_audio.tcl.  Its still mostly the original code, so it can
>> be scary. ;)
>>
>> Do you know how I can force configure to use Tcl/Tk 8.5.7/Carbon?
>>
>>
>> If you put a version of Tcl/Tk 8.5.7/Carbon frameworks into
>> /Library/Frameworks, it should use them over the build in ones.  But that
>> means using the Makefile in packages/darwin_app and running "make install".
>>  For development, I just rename a nighly build as "Pd-devel.app" then inside
>> the package, remove some guts and symlink it to my pd-gui-rewrite/0.43
>> sources:
>>
>> h...@palatschinken.at.or.at:src > ls -l
>> /Applications/Pd-devel.app/Contents/Resources/
>> total 152
>> lrwxr-xr-x   1 hans staff 3 2010-01-05 14:27 Scripts -> bin/
>> -r--r--r--   1 hans staff 47204 2008-08-14 20:03 VolumeIcon.icns
>> -r--r--r--   1 hans staff   545 2008-07-21 13:53 Wish.rsrc
>> lrwxr-xr-x   1 root staff59 2010-01-05 14:32 bin ->
>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/src/
>> dr-xr-xr-x  13 hans staff   442 2009-12-15 08:41 doc/
>> dr-xr-xr-x 180 hans staff  6120 2009-12-15 08:52 extra/
>> dr-xr-xr-x   6 hans staff   204 2009-12-15 08:41 include/
>> -r--r--r--   1 hans staff 42741 2008-02-14 18:14 pd-file.icns
>> -r--r--r--   1 hans staff 37100 2008-02-14 18:14 pd.icns
>> lrwxr-xr-x   1 root staff58 2010-01-05 14:31 po ->
>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/po/
>> dr-xr-xr-x   3 hans staff   102 2009-12-15 08:41 share/
>> lrwxr-xr-x   1 root staff63 2010-01-05 14:31 startup ->
>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/startup/
>>
>>
> I like this way of running the newest sources from within the app bundle,
> but I can't get it working yet.  I had to replace the executable in
> Contents/MacOS, but then it cannot find pd-gui.tcl (I removed the bin folder
> in the Resources directory and symlinked it to the pd-gui-rewrite/src/, like
> you did).
>
> rich
>
>
>
> Literally all I did was:
>
> - download nightly Pd-devel build
> - cd /path/to/Pd-devel.app/Contents/Resources
> - rm -rf bin
> - ln -s /path/to/pd-gui-rewrite/0.43/src bin
> - ln -s /path/to/pd-gui-rewrite/0.43/po
> - ln -s /path/to/pd-gui-rewrite/0.43/startup
>
> .hc
>
>
>
Really.  I do this and the executable in the Contents/MacOS folder is still
run and not the one in the symlinked directory.  Oh well.

Rich



>
>
>
>
>
>
>
>
>
>
>> .hc
>>
>>
>> I'll use the nightly build in the meantime and let you know what comes up.
>>
>> -rich
>>
>> On Mon, Jan 4, 2010 at 4:40 AM, Hans-Christoph Steiner wrote:
>>
>>>
>>> First off, which platform?  Is this still Mac OS X 10.6?  If so, 10.6 has
>>> a built-in custom version of Tcl/Tk 8.5.7 that uses Cocoa for the back end
>>> rather than Carbon.  Tcl/Tk 8.6 will only use this Cocoa backend, but will
>>> work on Mac OS X 10.5.  It would be good to flush out these bugs and report
>>> them to the tcl-mac list so that they can get fixed.
>>>
>>> One thing to try is using one of the nightly builds, which include Tcl/Tk
>>> 8.5.7/Carbon.  I think they should work on 10.6:
>>> http://autobuild.puredata.info/auto-build/latest/
>>>
>>>  On Nov 16, 2009, at 1:55 PM, Rich E

Re: [PD] 'synced' number and slider

[Rich E]

Ah that is nice, you just don't need the set messages. :)

I always looked at the iem gui objects as more sophisticated and better for
GUI front ends, not meant for writing a self-documenting patch.  They save
time and look/act better, but everyone I have met using pd for educational
purposes uses the more simple numberbox.

rich

On Sun, Jan 17, 2010 at 12:23 AM, Jonathan Wilkes wrote:

> I attached a modified version of your patch to show what I mean.  On the
> right, you can look at the patch and figure out the behavior before you
> scroll the gatom box (important if you want to make sure you're avoiding
> a buffer overflow).
>
> On the left, you have to read the source code for those GUI objects to
> figure out what's going to happen.  Judging from your original patch,
> I think you assumed that sending a float straight to the [nbx] would
> update the value in the slider (so did I).  This turns out not to be the
> case: the two GUIs are only bound together if you change the values on one
> of them using the mouse.
>
> If someone who reads and understands c better than me can explain why
> the iemgui magic works as it does, I'll be happy to document it.
>
> -Jonathan
>
>
>
> --- On Sat, 1/16/10, Rich E  wrote:
>
> > From: Rich E 
> > Subject: Re: [PD] 'synced' number and slider
> > To: "Jonathan Wilkes" 
> > Cc: "Lorenzo" , "IOhannes zmölnig" ,
> pd-list@iem.at
> > Date: Saturday, January 16, 2010, 8:38 PM
> > You can still send the set message directly
> > to the inlet of the numberbox2 or slider and it won't
> > effect the other.  See patch.
> >
> > 2010/1/16 Jonathan Wilkes 
> >
> >
> >
> >
> >
> > --- On Sat, 1/16/10, IOhannes zmölnig 
> > wrote:
> >
> >
> >
> > > From: IOhannes zmölnig 
> >
> > > Subject: Re: [PD] 'synced'
> > number and slider
> >
> > > To: "Lorenzo" 
> >
> > > Cc: pd-list@iem.at
> >
> > > Date: Saturday, January 16, 2010, 11:36 AM
> >
> > > Lorenzo wrote:
> >
> > > > This seems trivial but I've never managed to
> > figure
> >
> > > out how to do it in
> >
> > > > a non-trivial way:
> >
> > > >
> >
> > > > Have a number (atom) and a slider (be it
> > horizontal or
> >
> > > vertical) which
> >
> > > > are 'synced', that is if one changes the
> > number the
> >
> > > slider changes and
> >
> > > > vice-versa.
> >
> > >
> >
> > >
> >
> > > if you use numberbox2 as the numberbox, you can give
> > both
> >
> > > the nbx and
> >
> > > the slider the same send/receive names
> >
> > > (that is:
> >
> > >
> >
> numberbox2.sendname=numberbox2.receivename=slider.sendname=slider.receivename)
> >
> > >
> >
> > > and they will be magically linked to each other.
> >
> > >
> >
> > > to use the value in the patch add another receiver
> >
> > > [r ]
> >
> > >
> >
> >
> >
> > Except if you need to send a value to the inlet
> > of the numbox2 or the slider.  Then this method magically
> > doesn't work, whereas the [set $1(
> >
> > idiom does.
> >
> >
> >
> > > gfmadr
> >
> > > IOhannes
> >
> > >
> >
> > >
> >
> > > -Inline Attachment Follows-
> >
> > >
> >
> > > ___
> >
> > > Pd-list@iem.at
> >
> > > mailing list
> >
> > > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> >
> > Pd-list@iem.at
> > mailing list
> >
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> >
> >
> >
>
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-gui-rewrite testing

[Rich E]

On Sun, Jan 10, 2010 at 12:29 AM, Hans-Christoph Steiner wrote:

>
> On Jan 9, 2010, at 5:37 PM, Rich E wrote:
>
>
> Still in OS X 10.6.  I don't have one of these problems with Pd-devel-0.43
> (dec 15) nightly build, so it must all be because of the tk/cocoa version
> that you mention.  I'm not sure how to report it a tcl mailing list, as I
> don't know where the code is that implements these things.
>
> Does it make sense that the arrow keys are detected differently in
> Tk/Cocoa, so they are just sent to pd's gui C code as spaces?
>
>
> Not to me... it should be the same, that's why its worth reporting to
> tcl-mac.  You don't need to know the exact code that's causing the problem.
>  I read that list too, so I can fill in the details.  I just don't have
> access to a 10.6 machine these days.
>
> As for the text color issue in the audio settings, you'll have to point me
> towards what is controlling that.  I'll send you a screenshot after this
> email.
>
>
> Check out dialog_audio.tcl.  Its still mostly the original code, so it can
> be scary. ;)
>
> Do you know how I can force configure to use Tcl/Tk 8.5.7/Carbon?
>
>
> If you put a version of Tcl/Tk 8.5.7/Carbon frameworks into
> /Library/Frameworks, it should use them over the build in ones.  But that
> means using the Makefile in packages/darwin_app and running "make install".
>  For development, I just rename a nighly build as "Pd-devel.app" then inside
> the package, remove some guts and symlink it to my pd-gui-rewrite/0.43
> sources:
>
> h...@palatschinken.at.or.at:src > ls -l
> /Applications/Pd-devel.app/Contents/Resources/
> total 152
> lrwxr-xr-x   1 hans staff 3 2010-01-05 14:27 Scripts -> bin/
> -r--r--r--   1 hans staff 47204 2008-08-14 20:03 VolumeIcon.icns
> -r--r--r--   1 hans staff   545 2008-07-21 13:53 Wish.rsrc
> lrwxr-xr-x   1 root staff59 2010-01-05 14:32 bin ->
> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/src/
> dr-xr-xr-x  13 hans staff   442 2009-12-15 08:41 doc/
> dr-xr-xr-x 180 hans staff  6120 2009-12-15 08:52 extra/
> dr-xr-xr-x   6 hans staff   204 2009-12-15 08:41 include/
> -r--r--r--   1 hans staff 42741 2008-02-14 18:14 pd-file.icns
> -r--r--r--   1 hans staff 37100 2008-02-14 18:14 pd.icns
> lrwxr-xr-x   1 root staff58 2010-01-05 14:31 po ->
> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/po/
> dr-xr-xr-x   3 hans staff   102 2009-12-15 08:41 share/
> lrwxr-xr-x   1 root staff63 2010-01-05 14:31 startup ->
> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/startup/
>
>
I like this way of running the newest sources from within the app bundle,
but I can't get it working yet.  I had to replace the executable in
Contents/MacOS, but then it cannot find pd-gui.tcl (I removed the bin folder
in the Resources directory and symlinked it to the pd-gui-rewrite/src/, like
you did).

rich


> .hc
>
>
> I'll use the nightly build in the meantime and let you know what comes up.
>
> -rich
>
> On Mon, Jan 4, 2010 at 4:40 AM, Hans-Christoph Steiner wrote:
>
>>
>> First off, which platform?  Is this still Mac OS X 10.6?  If so, 10.6 has
>> a built-in custom version of Tcl/Tk 8.5.7 that uses Cocoa for the back end
>> rather than Carbon.  Tcl/Tk 8.6 will only use this Cocoa backend, but will
>> work on Mac OS X 10.5.  It would be good to flush out these bugs and report
>> them to the tcl-mac list so that they can get fixed.
>>
>> One thing to try is using one of the nightly builds, which include Tcl/Tk
>> 8.5.7/Carbon.  I think they should work on 10.6:
>> http://autobuild.puredata.info/auto-build/latest/
>>
>>  On Nov 16, 2009, at 1:55 PM, Rich E wrote:
>>
>>  Hi List, Hans,
>>>
>>> I've been using the pd-gui-rewrite-0.43 svn for a couple days now and
>>> here are some notes I've taken when finding various bugs (is the better sent
>>> to the pd-dev list?):
>>>
>>> • In Audio Settings, the text in the drop down menus is hardly visible
>>> because it is very light grey
>>>
>>
>> Never seen that, screenshot?
>>
>>
>>  • there is a new menu item called 'apple' with "about pd" and
>>> preferences"
>>>
>>
>> Known issue with the Tk/Cocoa, haven't found a workaround yet.
>>
>>
>>  • editing an object name:
>>> ‣ moving with arrows adds a space to the end, but does not move within
>>> the object name
>>>
>>
>> Hmm, can't reproduce, Tk/Cocoa issue?
>>
>>
>>  • opening &

Re: [PD] Problem with Snow Leopard and Flext

[Rich E]

I have been working with a flext external in Snow Leopard, but I did not
have any success getting it to work with Pd Extended (long story, it is a
wacom external that is dealing with all the Carbon/Cocoa problems that
currently exist).

I compile everything with CFLAGS="-arch i386".  No seg faults related to
flext.  I think, from this post and the one below, that flext is linked as
64bit.  I just today had to reinstall all my pd stuff because of a hard
drive crash and after making sure everything is cleanly built as 32bit, no
problems (again, in Snow Leopard).


2010/1/14 Cécile Picard-Limpens 

>  Dear List,
>
> I'm encountering the same problem as Miguel.. (message on *Sat Dec 12*).
> I'm using Apple Snow Leopard (10.6.2) on my macbook (2.26 GHz Intel Core
> Duo).
> As anyone succeeded building and launching flext objects using OSX Snow
> Leopard?
> It compiles but crashes at launching without error messages...
>
> Does it mean that the Pd-extended version compiled with x86_64 is needed?
>
> Thanks for your help!
>
> Cecile.
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-gui-rewrite testing

[Rich E]

I finally have a custom build of Tcl/Tk 8.5 Carbon that I can swap with the
Tcl/Tk 8.5 Cocoa  included with Snow Leopard.  This is the source of the
problems :)  So I'll try to address them one-by-one on the tcl-mac list and
spare the pd folks.

As of today, building from svn still creates the "Apple" menu item, I don't
know if you had tried to fix this or not yet.

One thing I noticed is that building pd with the Carbon Tcl/Tk version gives
an "about Tcl/Tk" menu option in the "Wish" menu, but this is replaced with
the "About pd" menu item when using Tcl/Tk Carbon - why so?  It seems
appropriate to have it when Pd can be compiled with different versions of
Tcl/Tk and the results can greatly differ.

Rich

On Tue, Jan 12, 2010 at 11:30 PM, Hans-Christoph Steiner wrote:

>
> So based on what they said in tcl-mac, we just need to test for 'AppKit'
> and only do the $mymenu.apple stuff if using Tk Carbon (i.e. no "AppKit" in
> [winfo server .] ).  I added two new functions for dealing with the special
> Apple menus:
>
>
> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=12970
>
>
> .hc
>
> On Jan 12, 2010, at 8:44 AM, Rich E wrote:
>
> Hello,
>
> I am forwarding this to the tcl-mac list too, as this question is probably
> more appropriate there.
>
> On Sun, Jan 10, 2010 at 12:29 AM, Hans-Christoph Steiner wrote:
>
>>
>> On Jan 9, 2010, at 5:37 PM, Rich E wrote:
>>
>>
>> Still in OS X 10.6.  I don't have one of these problems with Pd-devel-0.43
>> (dec 15) nightly build, so it must all be because of the tk/cocoa version
>> that you mention.  I'm not sure how to report it a tcl mailing list, as I
>> don't know where the code is that implements these things.
>>
>> Does it make sense that the arrow keys are detected differently in
>> Tk/Cocoa, so they are just sent to pd's gui C code as spaces?
>>
>>
>> Not to me... it should be the same, that's why its worth reporting to
>> tcl-mac.  You don't need to know the exact code that's causing the problem.
>>  I read that list too, so I can fill in the details.  I just don't have
>> access to a 10.6 machine these days.
>>
>> As for the text color issue in the audio settings, you'll have to point me
>> towards what is controlling that.  I'll send you a screenshot after this
>> email.
>>
>>
>> Check out dialog_audio.tcl.  Its still mostly the original code, so it can
>> be scary. ;)
>>
>> Do you know how I can force configure to use Tcl/Tk 8.5.7/Carbon?
>>
>>
>> If you put a version of Tcl/Tk 8.5.7/Carbon frameworks into
>> /Library/Frameworks, it should use them over the build in ones.
>>
>
> How do I get the Carbon-specific version (or know that it is not Cocoa)?  I
> built and installed Tcl/Tk 8.5.8, but I don't see any Tcl/Tk 8.5.8/Carbon
> framework, or any directions on how to build it specifically.
>
> I think it would be best for me to test this before reporting any bugs,
> although it seems clear  enough this is where the problem lays for building
> Pd (dev branch) from source on Snow Leopard.
>
> - rich
>
>
>
>>  But that means using the Makefile in packages/darwin_app and running
>> "make install".  For development, I just rename a nighly build as
>> "Pd-devel.app" then inside the package, remove some guts and symlink it to
>> my pd-gui-rewrite/0.43 sources:
>>
>> h...@palatschinken.at.or.at:src > ls -l
>> /Applications/Pd-devel.app/Contents/Resources/
>> total 152
>> lrwxr-xr-x   1 hans staff 3 2010-01-05 14:27 Scripts -> bin/
>> -r--r--r--   1 hans staff 47204 2008-08-14 20:03 VolumeIcon.icns
>> -r--r--r--   1 hans staff   545 2008-07-21 13:53 Wish.rsrc
>> lrwxr-xr-x   1 root staff59 2010-01-05 14:32 bin ->
>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/src/
>> dr-xr-xr-x  13 hans staff   442 2009-12-15 08:41 doc/
>> dr-xr-xr-x 180 hans staff  6120 2009-12-15 08:52 extra/
>> dr-xr-xr-x   6 hans staff   204 2009-12-15 08:41 include/
>> -r--r--r--   1 hans staff 42741 2008-02-14 18:14 pd-file.icns
>> -r--r--r--   1 hans staff 37100 2008-02-14 18:14 pd.icns
>> lrwxr-xr-x   1 root staff58 2010-01-05 14:31 po ->
>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/po/
>> dr-xr-xr-x   3 hans staff   102 2009-12-15 08:41 share/
>> lrwxr-xr-x   1 root staff63 2010-01-05 14:31 startup ->
>> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/startup/
>>
>> .hc
>>
>>
>> I'll use the nigh

Re: [PD] 'synced' number and slider

[Rich E]

You can still send the set message directly to the inlet of the numberbox2
or slider and it won't effect the other.  See patch.

2010/1/16 Jonathan Wilkes 

>
>
> --- On Sat, 1/16/10, IOhannes zmölnig  wrote:
>
> > From: IOhannes zmölnig 
> > Subject: Re: [PD] 'synced' number and slider
> > To: "Lorenzo" 
> > Cc: pd-list@iem.at
> > Date: Saturday, January 16, 2010, 11:36 AM
> > Lorenzo wrote:
> > > This seems trivial but I've never managed to figure
> > out how to do it in
> > > a non-trivial way:
> > >
> > > Have a number (atom) and a slider (be it horizontal or
> > vertical) which
> > > are 'synced', that is if one changes the number the
> > slider changes and
> > > vice-versa.
> >
> >
> > if you use numberbox2 as the numberbox, you can give both
> > the nbx and
> > the slider the same send/receive names
> > (that is:
> >
> numberbox2.sendname=numberbox2.receivename=slider.sendname=slider.receivename)
> >
> > and they will be magically linked to each other.
> >
> > to use the value in the patch add another receiver
> > [r ]
> >
>
> Except if you need to send a value to the inlet of the numbox2 or the
> slider.  Then this method magically doesn't work, whereas the [set $1(
> idiom does.
>
> > gfmadr
> > IOhannes
> >
> >
> > -Inline Attachment Follows-
> >
> > ___
> > Pd-list@iem.at
> > mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
>
>
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>


synced-nbx-slider-ex.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-gui-rewrite testing

[Rich E]

Hello,

I am forwarding this to the tcl-mac list too, as this question is probably
more appropriate there.

On Sun, Jan 10, 2010 at 12:29 AM, Hans-Christoph Steiner wrote:

>
> On Jan 9, 2010, at 5:37 PM, Rich E wrote:
>
>
> Still in OS X 10.6.  I don't have one of these problems with Pd-devel-0.43
> (dec 15) nightly build, so it must all be because of the tk/cocoa version
> that you mention.  I'm not sure how to report it a tcl mailing list, as I
> don't know where the code is that implements these things.
>
> Does it make sense that the arrow keys are detected differently in
> Tk/Cocoa, so they are just sent to pd's gui C code as spaces?
>
>
> Not to me... it should be the same, that's why its worth reporting to
> tcl-mac.  You don't need to know the exact code that's causing the problem.
>  I read that list too, so I can fill in the details.  I just don't have
> access to a 10.6 machine these days.
>
> As for the text color issue in the audio settings, you'll have to point me
> towards what is controlling that.  I'll send you a screenshot after this
> email.
>
>
> Check out dialog_audio.tcl.  Its still mostly the original code, so it can
> be scary. ;)
>
> Do you know how I can force configure to use Tcl/Tk 8.5.7/Carbon?
>
>
> If you put a version of Tcl/Tk 8.5.7/Carbon frameworks into
> /Library/Frameworks, it should use them over the build in ones.
>

How do I get the Carbon-specific version (or know that it is not Cocoa)?  I
built and installed Tcl/Tk 8.5.8, but I don't see any Tcl/Tk 8.5.8/Carbon
framework, or any directions on how to build it specifically.

I think it would be best for me to test this before reporting any bugs,
although it seems clear  enough this is where the problem lays for building
Pd (dev branch) from source on Snow Leopard.

- rich



>  But that means using the Makefile in packages/darwin_app and running "make
> install".  For development, I just rename a nighly build as "Pd-devel.app"
> then inside the package, remove some guts and symlink it to my
> pd-gui-rewrite/0.43 sources:
>
> h...@palatschinken.at.or.at:src > ls -l
> /Applications/Pd-devel.app/Contents/Resources/
> total 152
> lrwxr-xr-x   1 hans staff 3 2010-01-05 14:27 Scripts -> bin/
> -r--r--r--   1 hans staff 47204 2008-08-14 20:03 VolumeIcon.icns
> -r--r--r--   1 hans staff   545 2008-07-21 13:53 Wish.rsrc
> lrwxr-xr-x   1 root staff59 2010-01-05 14:32 bin ->
> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/src/
> dr-xr-xr-x  13 hans staff   442 2009-12-15 08:41 doc/
> dr-xr-xr-x 180 hans staff  6120 2009-12-15 08:52 extra/
> dr-xr-xr-x   6 hans staff   204 2009-12-15 08:41 include/
> -r--r--r--   1 hans staff 42741 2008-02-14 18:14 pd-file.icns
> -r--r--r--   1 hans staff 37100 2008-02-14 18:14 pd.icns
> lrwxr-xr-x   1 root staff58 2010-01-05 14:31 po ->
> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/po/
> dr-xr-xr-x   3 hans staff   102 2009-12-15 08:41 share/
> lrwxr-xr-x   1 root staff63 2010-01-05 14:31 startup ->
> /Users/hans/code/pure-data/branches/pd-gui-rewrite/0.43/startup/
>
> .hc
>
>
> I'll use the nightly build in the meantime and let you know what comes up.
>
> -rich
>
> On Mon, Jan 4, 2010 at 4:40 AM, Hans-Christoph Steiner wrote:
>
>>
>> First off, which platform?  Is this still Mac OS X 10.6?  If so, 10.6 has
>> a built-in custom version of Tcl/Tk 8.5.7 that uses Cocoa for the back end
>> rather than Carbon.  Tcl/Tk 8.6 will only use this Cocoa backend, but will
>> work on Mac OS X 10.5.  It would be good to flush out these bugs and report
>> them to the tcl-mac list so that they can get fixed.
>>
>> One thing to try is using one of the nightly builds, which include Tcl/Tk
>> 8.5.7/Carbon.  I think they should work on 10.6:
>> http://autobuild.puredata.info/auto-build/latest/
>>
>>  On Nov 16, 2009, at 1:55 PM, Rich E wrote:
>>
>>  Hi List, Hans,
>>>
>>> I've been using the pd-gui-rewrite-0.43 svn for a couple days now and
>>> here are some notes I've taken when finding various bugs (is the better sent
>>> to the pd-dev list?):
>>>
>>> • In Audio Settings, the text in the drop down menus is hardly visible
>>> because it is very light grey
>>>
>>
>> Never seen that, screenshot?
>>
>>
>>  • there is a new menu item called 'apple' with "about pd" and
>>> preferences"
>>>
>>
>> Known issue with the Tk/Cocoa, haven't found a workaround yet.
>>
>>
>>  • editing an object name:
>>> ‣ moving with arrow

Re: [PD] pd-gui-rewrite testing

[Rich E]

Still in OS X 10.6.  I don't have one of these problems with Pd-devel-0.43
(dec 15) nightly build, so it must all be because of the tk/cocoa version
that you mention.  I'm not sure how to report it a tcl mailing list, as I
don't know where the code is that implements these things.

Does it make sense that the arrow keys are detected differently in Tk/Cocoa,
so they are just sent to pd's gui C code as spaces?

As for the text color issue in the audio settings, you'll have to point me
towards what is controlling that.  I'll send you a screenshot after this
email.

Do you know how I can force configure to use Tcl/Tk 8.5.7/Carbon?

I'll use the nightly build in the meantime and let you know what comes up.

-rich

On Mon, Jan 4, 2010 at 4:40 AM, Hans-Christoph Steiner wrote:

>
> First off, which platform?  Is this still Mac OS X 10.6?  If so, 10.6 has a
> built-in custom version of Tcl/Tk 8.5.7 that uses Cocoa for the back end
> rather than Carbon.  Tcl/Tk 8.6 will only use this Cocoa backend, but will
> work on Mac OS X 10.5.  It would be good to flush out these bugs and report
> them to the tcl-mac list so that they can get fixed.
>
> One thing to try is using one of the nightly builds, which include Tcl/Tk
> 8.5.7/Carbon.  I think they should work on 10.6:
> http://autobuild.puredata.info/auto-build/latest/
>
> On Nov 16, 2009, at 1:55 PM, Rich E wrote:
>
>  Hi List, Hans,
>>
>> I've been using the pd-gui-rewrite-0.43 svn for a couple days now and here
>> are some notes I've taken when finding various bugs (is the better sent to
>> the pd-dev list?):
>>
>> • In Audio Settings, the text in the drop down menus is hardly visible
>> because it is very light grey
>>
>
> Never seen that, screenshot?
>
>
>  • there is a new menu item called 'apple' with "about pd" and preferences"
>>
>
> Known issue with the Tk/Cocoa, haven't found a workaround yet.
>
>
>  • editing an object name:
>> ‣ moving with arrows adds a space to the end, but does not move within the
>> object name
>>
>
> Hmm, can't reproduce, Tk/Cocoa issue?
>
>
>  • opening "about pd" gives an error:
>> ‣ Error: can't read "pd_myversion": no such variable"
>> ‣ an't read "pd_myversion": no such variable
>> can't read "pd_myversion": no such variable
>>while executing
>> "regsub -all PD_VERSION $bigstring2 $pd_myversion bigstring3"
>>(procedure "::pd_menucommands::menu_opentext" line 15)
>>invoked from within
>> "::pd_menucommands::menu_opentext "$dirname/$basename""
>>(".txt" arm line 1)
>>invoked from within
>> "switch -- [string tolower [file extension $basename]] {
>>".txt"{::pd_menucommands::menu_opentext "$dirname/$basename"
>>} ".c"{::..."
>>(procedure "menu_doc_open" line 4)
>>invoked from within
>> "menu_doc_open doc/1.manual 1.introduction.txt"
>>(menu invoke)
>>
>
> Its not implemented yet...  I was hoping to make "About Pd" a pd patch.
>
>
>  I have some time on my hands now that I finished my Master's, and frankly
>> I think the pd-vanilla GUI is unpleasant, so I could learn tcl/tk and help
>> out, if needed.
>>
>
> That would be great!  Your reports have already been helpful.  I'm going to
> be in pretty deep this month till its finished and merged into Miller's 0.43
> version.  He's been relatively scarse on the lists, but we've been working
> thru this stuff off-list.
>
> .hc
>
>
> 
>
> "Making boring techno music is really easy with modern tools, but with live
> coding, boring techno is much harder." - Chris McCormick
>
>
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling pd vanilla problems on OS X 10.6 Snow Leopard

[Rich E]

I see the "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" in the gcc call, which
is hardcoded into the configure.in/configure scripts.  In order to even get
things to build at all in OS X 10.6, I had to take all that stuff out, so
that it could find the headers in the /usr/include.  I dunno why this was
ever there, must have made things work in older versions of OS X, but not
now.

I think it is important to get vanilla compiling, even though the
gui-rewrite branch takes care of these issues.  It will probably be a while
before 0.43, anyway.

- rich


On Thu, Dec 31, 2009 at 6:10 PM, Jaime Oliver wrote:

> Hi,
>
> sorry for the lack of involvement so far! I'm willing to benchmark any
> tests needed.
>
> something very weird has happened...
>
> I compiled it without any evident problems and have used it fine, for
> a while. The config log for that build is attached as config.log
>
> However, I just downloaded it again and tried to compile and got a
> bunch of errors. I am attaching the output to the console as
> console-output.txt and the config log for that build as
> config-error.log.
>
> Is it possible there has been a change in pd-0.42-5?
>
> J
>
>
>
>
> On Wed, Dec 30, 2009 at 7:09 PM, Rich E  wrote:
> > I listed some notes about the problems I was having with the gui rewrite,
> > most problematic is that you can't navigate in text with arrows.  Should
> I
> > file bug reports or is the list fine for this?
> > pd-gui-rewrite compiled with tcl/tk 8.5, but vanilla/extended ships with
> > 8.4.  I'd like to compile them with 8.5 to see if that is adding the
> > functionality.
> > both versions of libPdTCL.dylib, compiled and from the dmg, are i386
> 32-bit.
> >  I don't know why the compiled version complains that this is the wrong
> > architecture while the dmg version doesn't.
> > Has anyone compiled a working version of pd vanilla in Snow Leopard?
> Jaime?
> > On Tue, Dec 29, 2009 at 6:15 PM, Hans-Christoph Steiner 
> > wrote:
> >>
> >> On Dec 28, 2009, at 1:19 PM, Rich E wrote:
> >>
> >> Hans,
> >>
> >> The gui rewrite version works fine on my computer, but I need
> >> Pd-Vanilla/Extented for testing purposes.  Not to mention, there are
> various
> >> small bugs in the gui rewrite branch that make it difficult to use when
> I'm
> >> making music.
> >>
> >> Please report them, so that I can fix them.  Now's the time for the
> final
> >> push on the new GUI code since Miller is working on tying it all into
> the
> >> 0.43 release.
> >>
> >> The problem is also that the wacom external I am working with * only *
> >> works with the pd-gui-rewrite branch, but I don't know if that is
> because I
> >> compiled it from source (with maybe a different version of Tcl/Tk) or
> >> because you re-wrote the Tk code to use Apple Events in a different way.
> >>
> >> I didn't really do anything explicit with Apple Events, but it is a
> >> ground-up rewrite.  Depending on where you got your build, it could be
> using
> >> Tcl/Tk 8.5.  You can check that with the [hcs/tcl_version] object.
> >>
> >> About 64-bit, I've decided to just compile all my music software as
> 32-bit
> >> for now, it seems to be too early for most apps still to run everything
> as
> >> 64-bit (and no real gain any way).  Most everything pre-compiled (ex.
> >> pd-extended) is 32-bit, anyway.
> >>
> >> So, that said, anyone have any suggestions on what is going wrong with
> my
> >> libPdTcl.dylib? The version included with Pd-extended is also i386, yet
> tk
> >> doesn't complain about it when running Wish...
> >>
> >> Run "file libPdTcl.dylib" to see what kind of binary it is.  That whole
> >> thing is such a kludge... I shudder to even think about it.  Plus its
> >> totally gone in 0.43.  As for 64-bit, that's something we do need to get
> >> fixed.
> >> .hc
> >>
> >> Rich
> >>
> >> On Mon, Dec 28, 2009 at 8:52 PM, Hans-Christoph Steiner 
> >> wrote:
> >>>
> >>> Try the 0.43/pd-gui-rewrite branch, with the new autotools build
> system.
> >>>  I think it should build properly on Mac OS X 64-bit:
> >>> http://puredata.info/dev/PdGuiRewrite
> >>> If not, report problems here and I try to fix them and commit them.
> >>> .hc
> >>> On Dec 27, 2009, at 10:25 AM, Rich E wrote:
> >>>
> >>> On I go.
> >>>
> >&

Re: [PD] compiling pd vanilla problems on OS X 10.6 Snow Leopard

[Rich E]

I listed some notes about the problems I was having with the gui rewrite,
most problematic is that you can't navigate in text with arrows.  Should I
file bug reports or is the list fine for this?

pd-gui-rewrite compiled with tcl/tk 8.5, but vanilla/extended ships with
8.4.  I'd like to compile them with 8.5 to see if that is adding the
functionality.

both versions of libPdTCL.dylib, compiled and from the dmg, are i386 32-bit.
 I don't know why the compiled version complains that this is the wrong
architecture while the dmg version doesn't.

Has anyone compiled a working version of pd vanilla in Snow Leopard? Jaime?

On Tue, Dec 29, 2009 at 6:15 PM, Hans-Christoph Steiner wrote:

>
> On Dec 28, 2009, at 1:19 PM, Rich E wrote:
>
> Hans,
>
> The gui rewrite version works fine on my computer, but I need
> Pd-Vanilla/Extented for testing purposes.  Not to mention, there are various
> small bugs in the gui rewrite branch that make it difficult to use when I'm
> making music.
>
>
> Please report them, so that I can fix them.  Now's the time for the final
> push on the new GUI code since Miller is working on tying it all into the
> 0.43 release.
>
> The problem is also that the wacom external I am working with * only *
> works with the pd-gui-rewrite branch, but I don't know if that is because I
> compiled it from source (with maybe a different version of Tcl/Tk) or
> because you re-wrote the Tk code to use Apple Events in a different way.
>
>
> I didn't really do anything explicit with Apple Events, but it is a
> ground-up rewrite.  Depending on where you got your build, it could be using
> Tcl/Tk 8.5.  You can check that with the [hcs/tcl_version] object.
>
> About 64-bit, I've decided to just compile all my music software as 32-bit
> for now, it seems to be too early for most apps still to run everything as
> 64-bit (and no real gain any way).  Most everything pre-compiled (ex.
> pd-extended) is 32-bit, anyway.
>
> So, that said, anyone have any suggestions on what is going wrong with my
> libPdTcl.dylib? The version included with Pd-extended is also i386, yet tk
> doesn't complain about it when running Wish...
>
>
> Run "file libPdTcl.dylib" to see what kind of binary it is.  That whole
> thing is such a kludge... I shudder to even think about it.  Plus its
> totally gone in 0.43.  As for 64-bit, that's something we do need to get
> fixed.
>
> .hc
>
>
> Rich
>
> On Mon, Dec 28, 2009 at 8:52 PM, Hans-Christoph Steiner wrote:
>
>>
>> Try the 0.43/pd-gui-rewrite branch, with the new autotools build system.
>>  I think it should build properly on Mac OS X 64-bit:
>>
>> http://puredata.info/dev/PdGuiRewrite
>>
>> If not, report problems here and I try to fix them and commit them.
>>
>> .hc
>>
>> On Dec 27, 2009, at 10:25 AM, Rich E wrote:
>>
>> On I go.
>>
>> Loading /usr/bin/wish turns out to be 64bit, but running pd from Miller's
>> pre-built app (or Pd-extended pre-built) creates a 32bit version.  When
>> compiling from source, I am making libPdTcl.dylib 32bit, but wish's 'load'
>> function thinks this is the wrong architecture - I think then that wish
>> needs to be run as 32bit, but I can't figure out how to do this or how the
>> pre-built app is doing this.  I can't find any doc's on that load function,
>> either (line 67 of pd.tk).
>>
>> I'm just shooting in the dark here, trying to conjure up some advice.  I
>> need to get pd compiled from source to work on an external.
>>
>> Rich
>>
>> On Sat, Dec 26, 2009 at 12:29 AM, Rich E  wrote:
>>
>>> I hope someone can help me fix the last problem on this list, it is
>>> blocking me (libPdTcl.dylib wrong architecture).  I can't see why it is
>>> detected as the wrong architecture, everything I check says it is i386
>>> compatible.
>>>
>>> I did remove alot from the configure.in file trying to get it work, so
>>> maybe there is a problem there.  It is attached.
>>>
>>> merry christmas, feliz navidad és boldog karácsonzyt (i think I may have
>>> barely missed it in my time)!
>>>
>>> - rich
>>>
>>>
>>> On Wed, Dec 23, 2009 at 4:44 AM, Rich E  wrote:
>>>
>>>> Hi,
>>>>
>>>> I am having problems compiling pd from Miller's website in OS X Snow
>>>> Leopard.  Basically, Pd fell behind Apple's updates.  Here are my problems,
>>>> fixes where I found them:
>>>>
>>>> - the configure script automatically adds -isysroot blah

Re: [PD] compiling pd vanilla problems on OS X 10.6 Snow Leopard

[Rich E]

Hans,

The gui rewrite version works fine on my computer, but I need
Pd-Vanilla/Extented for testing purposes.  Not to mention, there are various
small bugs in the gui rewrite branch that make it difficult to use when I'm
making music.

The problem is also that the wacom external I am working with * only * works
with the pd-gui-rewrite branch, but I don't know if that is because I
compiled it from source (with maybe a different version of Tcl/Tk) or
because you re-wrote the Tk code to use Apple Events in a different way.

About 64-bit, I've decided to just compile all my music software as 32-bit
for now, it seems to be too early for most apps still to run everything as
64-bit (and no real gain any way).  Most everything pre-compiled (ex.
pd-extended) is 32-bit, anyway.

So, that said, anyone have any suggestions on what is going wrong with my
libPdTcl.dylib? The version included with Pd-extended is also i386, yet tk
doesn't complain about it when running Wish...

Rich

On Mon, Dec 28, 2009 at 8:52 PM, Hans-Christoph Steiner wrote:

>
> Try the 0.43/pd-gui-rewrite branch, with the new autotools build system.  I
> think it should build properly on Mac OS X 64-bit:
>
> http://puredata.info/dev/PdGuiRewrite
>
> If not, report problems here and I try to fix them and commit them.
>
> .hc
>
> On Dec 27, 2009, at 10:25 AM, Rich E wrote:
>
> On I go.
>
> Loading /usr/bin/wish turns out to be 64bit, but running pd from Miller's
> pre-built app (or Pd-extended pre-built) creates a 32bit version.  When
> compiling from source, I am making libPdTcl.dylib 32bit, but wish's 'load'
> function thinks this is the wrong architecture - I think then that wish
> needs to be run as 32bit, but I can't figure out how to do this or how the
> pre-built app is doing this.  I can't find any doc's on that load function,
> either (line 67 of pd.tk).
>
> I'm just shooting in the dark here, trying to conjure up some advice.  I
> need to get pd compiled from source to work on an external.
>
> Rich
>
> On Sat, Dec 26, 2009 at 12:29 AM, Rich E  wrote:
>
>> I hope someone can help me fix the last problem on this list, it is
>> blocking me (libPdTcl.dylib wrong architecture).  I can't see why it is
>> detected as the wrong architecture, everything I check says it is i386
>> compatible.
>>
>> I did remove alot from the configure.in file trying to get it work, so
>> maybe there is a problem there.  It is attached.
>>
>> merry christmas, feliz navidad és boldog karácsonzyt (i think I may have
>> barely missed it in my time)!
>>
>> - rich
>>
>>
>> On Wed, Dec 23, 2009 at 4:44 AM, Rich E  wrote:
>>
>>> Hi,
>>>
>>> I am having problems compiling pd from Miller's website in OS X Snow
>>> Leopard.  Basically, Pd fell behind Apple's updates.  Here are my problems,
>>> fixes where I found them:
>>>
>>> - the configure script automatically adds -isysroot blah blah for the
>>> 10.4 sdk, which doesn't work.  this line is removed.
>>> - the included portaudio (and more importantly, its coreaudio components)
>>> with pd does not match the coreaudio framework included with Snow Leopard.
>>> There are lots of deprecations and finally undeclared methods.  I tried just
>>> updating the source code from that in portaudio's svn, but this led to
>>> further undefined calls that I don't remember.
>>> - using '-disable-portaudio' doesn't do any good because it is
>>> automatically added if you are on OS X (I wanted to just use jack since
>>> portaudio is outdated).
>>> - I had to remove all '-arch' flags except i386 to get everything linked.
>>>
>>> Okay, after that, it compiled. whew. Still, pd's gui will not run because
>>> libPdTcl.dylib either isn't found or is the wrong architecture, I still
>>> can't tell:
>>>
>>> $ pd -jack
>>> Error in startup script:
>>> dlopen(/usr/local/lib/pd/bin/../bin/libPdTcl.dylib, 10): no suitable image
>>> found.  Did find:
>>> /usr/local/lib/pd/bin/../bin/libPdTcl.dylib: mach-o, but wrong
>>> architecture
>>> while executing
>>> "load $pd_guidir/bin/libPdTcl.dylib"
>>> invoked from within
>>> "if {$pd_nt == 2} {
>>> # turn on James Tittle II's fast drawing
>>> set tk::mac::useCGDrawing 1
>>> # anti-alias all lines that need it
>>> set tk::mac::CGAnt..."
>>> (file "/usr/local/lib/pd/bin/pd.tk" line 67)
>>> ^CPd: signal 2
>>

Re: [PD] writing externals in xCode

[Rich E]

Hi,

Here is a guide:  http://puredata.info/docs/developer/PdExternalsInXcode/

- rich

On Mon, Dec 28, 2009 at 2:24 AM, sonia yuditskaya wrote:

> Hello Lovely List,
> Does anyone have experience writing externals in Xcode?
> Is there a place where I can look about setting up the proper linking and
> so on?
> Is there a bundle of headers and things I should be using already?
> Thanks a million!
> --
> Sonia Yuditskaya
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling pd vanilla problems on OS X 10.6 Snow Leopard

[Rich E]

On I go.

Loading /usr/bin/wish turns out to be 64bit, but running pd from Miller's
pre-built app (or Pd-extended pre-built) creates a 32bit version.  When
compiling from source, I am making libPdTcl.dylib 32bit, but wish's 'load'
function thinks this is the wrong architecture - I think then that wish
needs to be run as 32bit, but I can't figure out how to do this or how the
pre-built app is doing this.  I can't find any doc's on that load function,
either (line 67 of pd.tk).

I'm just shooting in the dark here, trying to conjure up some advice.  I
need to get pd compiled from source to work on an external.

Rich

On Sat, Dec 26, 2009 at 12:29 AM, Rich E  wrote:

> I hope someone can help me fix the last problem on this list, it is
> blocking me (libPdTcl.dylib wrong architecture).  I can't see why it is
> detected as the wrong architecture, everything I check says it is i386
> compatible.
>
> I did remove alot from the configure.in file trying to get it work, so
> maybe there is a problem there.  It is attached.
>
> merry christmas, feliz navidad és boldog karácsonzyt (i think I may have
> barely missed it in my time)!
>
> - rich
>
>
> On Wed, Dec 23, 2009 at 4:44 AM, Rich E  wrote:
>
>> Hi,
>>
>> I am having problems compiling pd from Miller's website in OS X Snow
>> Leopard.  Basically, Pd fell behind Apple's updates.  Here are my problems,
>> fixes where I found them:
>>
>> - the configure script automatically adds -isysroot blah blah for the 10.4
>> sdk, which doesn't work.  this line is removed.
>> - the included portaudio (and more importantly, its coreaudio components)
>> with pd does not match the coreaudio framework included with Snow Leopard.
>> There are lots of deprecations and finally undeclared methods.  I tried just
>> updating the source code from that in portaudio's svn, but this led to
>> further undefined calls that I don't remember.
>> - using '-disable-portaudio' doesn't do any good because it is
>> automatically added if you are on OS X (I wanted to just use jack since
>> portaudio is outdated).
>> - I had to remove all '-arch' flags except i386 to get everything linked.
>>
>> Okay, after that, it compiled. whew. Still, pd's gui will not run because
>> libPdTcl.dylib either isn't found or is the wrong architecture, I still
>> can't tell:
>>
>> $ pd -jack
>> Error in startup script:
>> dlopen(/usr/local/lib/pd/bin/../bin/libPdTcl.dylib, 10): no suitable image
>> found.  Did find:
>> /usr/local/lib/pd/bin/../bin/libPdTcl.dylib: mach-o, but wrong
>> architecture
>> while executing
>> "load $pd_guidir/bin/libPdTcl.dylib"
>> invoked from within
>> "if {$pd_nt == 2} {
>> # turn on James Tittle II's fast drawing
>> set tk::mac::useCGDrawing 1
>> # anti-alias all lines that need it
>> set tk::mac::CGAnt..."
>> (file "/usr/local/lib/pd/bin/pd.tk" line 67)
>> ^CPd: signal 2
>>
>> It is there, they are all i386 and tcl/tk are universal binaries, so I
>> don't know.  Anyone else?
>>
>> Running pd with no gui and jack works.
>>
>> regards,
>> Rich
>>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling pd vanilla problems on OS X 10.6 Snow Leopard

[Rich E]

I hope someone can help me fix the last problem on this list, it is blocking
me (libPdTcl.dylib wrong architecture).  I can't see why it is detected as
the wrong architecture, everything I check says it is i386 compatible.

I did remove alot from the configure.in file trying to get it work, so maybe
there is a problem there.  It is attached.

merry christmas, feliz navidad és boldog karácsonzyt (i think I may have
barely missed it in my time)!

- rich

On Wed, Dec 23, 2009 at 4:44 AM, Rich E  wrote:

> Hi,
>
> I am having problems compiling pd from Miller's website in OS X Snow
> Leopard.  Basically, Pd fell behind Apple's updates.  Here are my problems,
> fixes where I found them:
>
> - the configure script automatically adds -isysroot blah blah for the 10.4
> sdk, which doesn't work.  this line is removed.
> - the included portaudio (and more importantly, its coreaudio components)
> with pd does not match the coreaudio framework included with Snow Leopard.
> There are lots of deprecations and finally undeclared methods.  I tried just
> updating the source code from that in portaudio's svn, but this led to
> further undefined calls that I don't remember.
> - using '-disable-portaudio' doesn't do any good because it is
> automatically added if you are on OS X (I wanted to just use jack since
> portaudio is outdated).
> - I had to remove all '-arch' flags except i386 to get everything linked.
>
> Okay, after that, it compiled. whew. Still, pd's gui will not run because
> libPdTcl.dylib either isn't found or is the wrong architecture, I still
> can't tell:
>
> $ pd -jack
> Error in startup script:
> dlopen(/usr/local/lib/pd/bin/../bin/libPdTcl.dylib, 10): no suitable image
> found.  Did find:
> /usr/local/lib/pd/bin/../bin/libPdTcl.dylib: mach-o, but wrong
> architecture
> while executing
> "load $pd_guidir/bin/libPdTcl.dylib"
> invoked from within
> "if {$pd_nt == 2} {
> # turn on James Tittle II's fast drawing
> set tk::mac::useCGDrawing 1
> # anti-alias all lines that need it
> set tk::mac::CGAnt..."
> (file "/usr/local/lib/pd/bin/pd.tk" line 67)
> ^CPd: signal 2
>
> It is there, they are all i386 and tcl/tk are universal binaries, so I
> don't know.  Anyone else?
>
> Running pd with no gui and jack works.
>
> regards,
> Rich
>


configure.in
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Range object

[Rich E]

there's a help file in svn in the folder externals/deprecated/help/.  I
guess it is deprecated :)

- rich

On Wed, Dec 23, 2009 at 8:11 PM, Hans-Christoph Steiner wrote:

>
> [range] is literally a copy of [maxlib/scale] that has been deprecated.
>  Use [maxlib/scale], which has a help patch.
>
> .hc
>
> On Dec 23, 2009, at 5:07 AM, Andrew Faraday wrote:
>
> Hey All
>
> I've just realized that the object [range], doesn't have a working help
> file, at least on my system.
>
> Is everyone else missing it?
>
> I've thrown a help file together, if anyone wants it, attached.
>
> God Bless
>
> Andrew Faraday
>
> --
> Add other email accounts to Hotmail in 3 easy steps. Find out 
> how.
>  ___
>
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
> 
>
> Computer science is no more related to the computer than astronomy is
> related to the telescope.  -Edsger Dykstra
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd external that uses cocoa / objective C

[Rich E]

I was running along the lines that if Cocoa uses Carbon to handle events,
and Cocoa is not usable on any other platform, why not use Carbon directly,
as the Wacom guys provide examples for using both.  It is not that I am
scared of ObjC, it is having to base the entire external in ObjC and then it
has to be completely rewritten for all other platforms.

I think the only real motivation I had behind using Cocoa was to learn it,
along with ObjC.  I thought compatibility would be another reason, but I am
not so sure any more.

Another related question for those more experienced then myself: can I have
the base of the external in C, then call methods from another source file
containing the Cocoa API in ObjC?


2009/12/23 IOhannes zmölnig 

> Rich E wrote:
> > Hmmm, after hearing back from the Cocoa-dev mailing list that all of
> Cocoa's
> > Event handling code is based on Carbon (and is 64-bit compatible, at
> least
> > the Event Handling), I don't know if it is worth it to write the external
> in
> > ObjC (which I will probably do poorly at that, as it is my first attempt
> > with the language).  Anyways, Carbon is written in C, the WinTab API is
> > written in C, so introducing ObjC may turn out to be a hassle later on
> > instead of allowing future compatibility?
>
> ??
> just because cocoa uses carbon as a backend for event handling this
> shouldn't scare you away from using ObjC. most low-level runtime
> libraries, are written in C - but it still makes sense to use a higher
> language (if it makes sense) to use them.
>
> ObjC is mostly a macOS thing; cocoa/carbon is obviously macos only.
> if you want crossplatform, then you shouldn't use it.
> if you want "native" macos support, it's a good choice (imho).
>
> learning a new language can still be fun.
>
> fg,arsd
> IOhannes
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] compiling pd vanilla problems on OS X 10.6 Snow Leopard

[Rich E]

Hi,

I am having problems compiling pd from Miller's website in OS X Snow
Leopard.  Basically, Pd fell behind Apple's updates.  Here are my problems,
fixes where I found them:

- the configure script automatically adds -isysroot blah blah for the 10.4
sdk, which doesn't work.  this line is removed.
- the included portaudio (and more importantly, its coreaudio components)
with pd does not match the coreaudio framework included with Snow Leopard.
There are lots of deprecations and finally undeclared methods.  I tried just
updating the source code from that in portaudio's svn, but this led to
further undefined calls that I don't remember.
- using '-disable-portaudio' doesn't do any good because it is automatically
added if you are on OS X (I wanted to just use jack since portaudio is
outdated).
- I had to remove all '-arch' flags except i386 to get everything linked.

Okay, after that, it compiled. whew. Still, pd's gui will not run because
libPdTcl.dylib either isn't found or is the wrong architecture, I still
can't tell:

$ pd -jack
Error in startup script: dlopen(/usr/local/lib/pd/bin/../bin/libPdTcl.dylib,
10): no suitable image found.  Did find:
/usr/local/lib/pd/bin/../bin/libPdTcl.dylib: mach-o, but wrong
architecture
while executing
"load $pd_guidir/bin/libPdTcl.dylib"
invoked from within
"if {$pd_nt == 2} {
# turn on James Tittle II's fast drawing
set tk::mac::useCGDrawing 1
# anti-alias all lines that need it
set tk::mac::CGAnt..."
(file "/usr/local/lib/pd/bin/pd.tk" line 67)
^CPd: signal 2

It is there, they are all i386 and tcl/tk are universal binaries, so I don't
know.  Anyone else?

Running pd with no gui and jack works.

regards,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] wacom / gemtablet / hid

[Rich E]

Oops, try /dev/input/event[whatever the event number is], maybe it work with
symbolic links (like [hid]).  I don't have an ubuntu machine around, so I
can only give suggestions, but you'll find a ton of posts about this topic
in pd and linuxwacom mailing lists.

You are probably having the same problems that I was having before I purged
my system of udev/hal.

I agree, getting a tablet to work properly in pd has become a pain (worse in
OS X and windows), but once you do, it makes for a great and cheap
controller.
Arg.. there was one post that I followed exactly on the ubuntu forums on how
to get rid of hal, but I can't find it :(  But, maybe this isn't the best
way anymore, maybe they got things working correctly. The linuxwacom list is
really helpful and always got me on the right track (since the problems were
changing as rapidly as Ubuntu).

Rich

On Tue, Dec 22, 2009 at 11:48 PM, cyrille henry  wrote:

> hello,
> i'm running the last ubuntu (9.10), using kernel 2.6.31
>
> hum, i don' really want to spend lot's of time tweaking stuff. it is sad to
> realize that using a wacom use to be very easy but it is no more...
>
> sudo wacdump /dev/input/wacom gives me a segmentation fault...
>
> thanks for your help
>
> Cyrille
>
> Rich E a écrit :
>
>> What distribution are you running?  In the newer Ubuntu's (ex Jaunty), I
>> had to do all sorts of things to get back the old (and working) xorg
>> configuration and stop using udev.  I have a ton of posts about this on the
>> linuxwacom-discuss mailing list and probably this one too, I think I was
>> having the same problems as you were then, and finally got it fixed (right
>> before my laptop was stolen and I bought a macbook :).  It may work better
>> now, probably with more tweaking, as that was 1/2 a year ago.
>>
>>
>> One thing to try; do you get any tablet data output using wacdump?
>>
>> Good luck getting it working, I'll try to help more if I can.
>>
>> Rich
>>
>> On Tue, Dec 22, 2009 at 11:21 PM, cyrille henry > c...@chnry.net>> wrote:
>>
>>argggh.
>>your are right : pd did not have permission to read the input device.
>>
>>starting pd as root help a bit : now both linuxevent and hid can
>>open the device.
>>but they does not send any data...
>>
>>
>>
>>thanks
>>Cyrille
>>
>>
>>
>>Rich E a écrit :
>>
>>Does pd have permissions to open /dev/input/wacom (or any of the
>>event*'s)?
>>On Tue, Dec 22, 2009 at 9:51 PM, cyrille henry ><mailto:c...@chnry.net> <mailto:c...@chnry.net
>>
>><mailto:c...@chnry.net>>> wrote:
>>
>>   the problem i have is that both does not work!
>>   :-)
>>
>>   c
>>
>>
>>   Rich E a écrit :
>>
>>   The problem that I had with /dev/input/even* devices is
>>that it
>>   always changes when you unplug/replug your tablet.
>>/dev/input/wacom is a symbolic link to the newly created
>>input,
>>   no matter what event* it is.
>>
>>   On Tue, Dec 22, 2009 at 8:18 PM, Hans-Christoph Steiner
>>   mailto:h...@at.or.at>
>><mailto:h...@at.or.at <mailto:h...@at.or.at>>
>><mailto:h...@at.or.at <mailto:h...@at.or.at>
>>
>>   <mailto:h...@at.or.at <mailto:h...@at.or.at>>>> wrote:
>>
>>
>>  [hid] uses the input.h struct, which the
>> /dev/input/event*
>>   devices
>>  give.  I don't know what /dev/input/wacom outputs.
>> Try using an
>>  /dev/input/event* device.
>>
>>  .hc
>>
>>
>>  On Dec 21, 2009, at 3:12 AM, cyrille henry wrote:
>>
>>  hello
>>
>>  few years go, i used a wacom with the [gemtablet]
>>object.
>>   this
>>  was working perfectly.
>>  but i now realize that this object is no more part
>>of Gem
>>   (since
>>  3 years).
>>  the dummy object that replace it say that one must
>> use
>>   hid instead.
>>  so did i.
>>
>>  but i failed making it work.
>>
>>  i'm using linux 

Re: [PD] wacom / gemtablet / hid

[Rich E]

What distribution are you running?  In the newer Ubuntu's (ex Jaunty), I had
to do all sorts of things to get back the old (and working) xorg
configuration and stop using udev.  I have a ton of posts about this on the
linuxwacom-discuss mailing list and probably this one too, I think I was
having the same problems as you were then, and finally got it fixed (right
before my laptop was stolen and I bought a macbook :).  It may work better
now, probably with more tweaking, as that was 1/2 a year ago.

One thing to try; do you get any tablet data output using wacdump?

Good luck getting it working, I'll try to help more if I can.

Rich

On Tue, Dec 22, 2009 at 11:21 PM, cyrille henry  wrote:

> argggh.
> your are right : pd did not have permission to read the input device.
>
> starting pd as root help a bit : now both linuxevent and hid can open the
> device.
> but they does not send any data...
>
>
>
> thanks
> Cyrille
>
>
>
> Rich E a écrit :
>
>> Does pd have permissions to open /dev/input/wacom (or any of the
>> event*'s)?
>> On Tue, Dec 22, 2009 at 9:51 PM, cyrille henry > c...@chnry.net>> wrote:
>>
>>the problem i have is that both does not work!
>>:-)
>>
>>c
>>
>>
>>Rich E a écrit :
>>
>>The problem that I had with /dev/input/even* devices is that it
>>always changes when you unplug/replug your tablet.
>> /dev/input/wacom is a symbolic link to the newly created input,
>>no matter what event* it is.
>>
>>On Tue, Dec 22, 2009 at 8:18 PM, Hans-Christoph Steiner
>>mailto:h...@at.or.at> <mailto:h...@at.or.at
>>
>><mailto:h...@at.or.at>>> wrote:
>>
>>
>>   [hid] uses the input.h struct, which the /dev/input/event*
>>devices
>>   give.  I don't know what /dev/input/wacom outputs.  Try using an
>>   /dev/input/event* device.
>>
>>   .hc
>>
>>
>>   On Dec 21, 2009, at 3:12 AM, cyrille henry wrote:
>>
>>   hello
>>
>>   few years go, i used a wacom with the [gemtablet] object.
>>this
>>   was working perfectly.
>>   but i now realize that this object is no more part of Gem
>>(since
>>   3 years).
>>   the dummy object that replace it say that one must use
>>hid instead.
>>   so did i.
>>
>>   but i failed making it work.
>>
>>   i'm using linux and hid from pd svn.
>>
>>   i send a "open /dev/input/wacom" message to the hid
>>object, and
>>   get as only answer : info: open 0
>>   info: device 0
>>
>>   if i start pooling, then the wacom did not work anymore,
>>and i
>>   have to reboot the computer to make it work again.
>>
>>   playing a bit more with that object made pd to crash.
>>
>>   any suggestion to make my wacom work with hid?
>>   any other object that could get data from a wacom?
>>   or should i try to get the old sources of gemtablet to
>>compile
>>   again???
>>
>>   thanks
>>   Cyrille
>>
>>
>>   ___
>>   Pd-list@iem.at <mailto:Pd-list@iem.at>
>><mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list
>>
>>
>>   UNSUBSCRIBE and account-management ->
>>   http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>>
>>
>> 
>>
>>   I spent 33 years and four months in active military service and
>>   during that period I spent most of my time as a high class
>> muscle
>>   man for Big Business, for Wall Street and the bankers.  -
>>   General Smedley Butler
>>
>>
>>
>>
>>   ___
>>   Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at
>>
>><mailto:Pd-list@iem.at>> mailing list
>>
>>   UNSUBSCRIBE and account-management ->
>>   http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>>
>> 
>>
>> ___
>>
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] wacom / gemtablet / hid

[Rich E]

Does pd have permissions to open /dev/input/wacom (or any of the event*'s)?


On Tue, Dec 22, 2009 at 9:51 PM, cyrille henry  wrote:

> the problem i have is that both does not work!
> :-)
>
> c
>
>
> Rich E a écrit :
>
>> The problem that I had with /dev/input/even* devices is that it always
>> changes when you unplug/replug your tablet.  /dev/input/wacom is a symbolic
>> link to the newly created input, no matter what event* it is.
>>
>> On Tue, Dec 22, 2009 at 8:18 PM, Hans-Christoph Steiner 
>> > h...@at.or.at>> wrote:
>>
>>
>>[hid] uses the input.h struct, which the /dev/input/event* devices
>>give.  I don't know what /dev/input/wacom outputs.  Try using an
>>/dev/input/event* device.
>>
>>.hc
>>
>>
>>On Dec 21, 2009, at 3:12 AM, cyrille henry wrote:
>>
>>hello
>>
>>few years go, i used a wacom with the [gemtablet] object. this
>>was working perfectly.
>>but i now realize that this object is no more part of Gem (since
>>3 years).
>>the dummy object that replace it say that one must use hid instead.
>>so did i.
>>
>>but i failed making it work.
>>
>>i'm using linux and hid from pd svn.
>>
>>i send a "open /dev/input/wacom" message to the hid object, and
>>get as only answer : info: open 0
>>info: device 0
>>
>>if i start pooling, then the wacom did not work anymore, and i
>>have to reboot the computer to make it work again.
>>
>>playing a bit more with that object made pd to crash.
>>
>>any suggestion to make my wacom work with hid?
>>any other object that could get data from a wacom?
>>or should i try to get the old sources of gemtablet to compile
>>again???
>>
>>thanks
>>Cyrille
>>
>>
>>___
>>Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list
>>
>>UNSUBSCRIBE and account-management ->
>>http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>>
>>
>>  
>>
>>I spent 33 years and four months in active military service and
>>during that period I spent most of my time as a high class muscle
>>man for Big Business, for Wall Street and the bankers.  -
>>General Smedley Butler
>>
>>
>>
>>
>>___
>>Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list
>>
>>UNSUBSCRIBE and account-management ->
>>http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] wacom / gemtablet / hid

[Rich E]

The problem that I had with /dev/input/even* devices is that it always
changes when you unplug/replug your tablet.  /dev/input/wacom is a symbolic
link to the newly created input, no matter what event* it is.

On Tue, Dec 22, 2009 at 8:18 PM, Hans-Christoph Steiner wrote:

>
> [hid] uses the input.h struct, which the /dev/input/event* devices give.  I
> don't know what /dev/input/wacom outputs.  Try using an /dev/input/event*
> device.
>
> .hc
>
>
> On Dec 21, 2009, at 3:12 AM, cyrille henry wrote:
>
>  hello
>>
>> few years go, i used a wacom with the [gemtablet] object. this was working
>> perfectly.
>> but i now realize that this object is no more part of Gem (since 3 years).
>> the dummy object that replace it say that one must use hid instead.
>> so did i.
>>
>> but i failed making it work.
>>
>> i'm using linux and hid from pd svn.
>>
>> i send a "open /dev/input/wacom" message to the hid object, and get as
>> only answer : info: open 0
>> info: device 0
>>
>> if i start pooling, then the wacom did not work anymore, and i have to
>> reboot the computer to make it work again.
>>
>> playing a bit more with that object made pd to crash.
>>
>> any suggestion to make my wacom work with hid?
>> any other object that could get data from a wacom?
>> or should i try to get the old sources of gemtablet to compile again???
>>
>> thanks
>> Cyrille
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>
>
> 
>
> I spent 33 years and four months in active military service and during that
> period I spent most of my time as a high class muscle man for Big Business,
> for Wall Street and the bankers.  - General Smedley Butler
>
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] wacom / gemtablet / hid

[Rich E]

I'm not in front of a Linux machine at the moment, but I was using a Wacom
tablet in linux for the last couple years.  [HID] doesn't work with calling
the symbolic links in /dev/input/. I was able to get the tablet to send out
data with [hid] by going through the [open $1( with all indeces, clicking on
[info(, then seeing if it was the tablet.  I tried various ways to automate
this with the output info strings but never got anything to work
consistently.  This, and that I didn't like the way control data was output,
made me switch back to using [linuxevent].  It works just find with [open
/dev/input/wacom ( and the data is easy to interpret in pd.  I attached a
(very dirty) patch that I used to route the control data with [linuxevent],
hope it saves you some time.

Tablets don't seem to work well with [hid] in any platform (not in windows
either, right?), not at all in OS X, the platform I am now on.  I'm
re-writing a general purpose [tablet] external right now that will at first
only work in OS X, but hopefully it can cover all platforms later on down
the road.  It is just that the API is different for the three big ones, mac,
linux, and windows.

regards,
Rich

On Mon, Dec 21, 2009 at 12:12 PM, cyrille henry  wrote:

> hello
>
> few years go, i used a wacom with the [gemtablet] object. this was working
> perfectly.
> but i now realize that this object is no more part of Gem (since 3 years).
> the dummy object that replace it say that one must use hid instead.
> so did i.
>
> but i failed making it work.
>
> i'm using linux and hid from pd svn.
>
> i send a "open /dev/input/wacom" message to the hid object, and get as only
> answer : info: open 0
> info: device 0
>
> if i start pooling, then the wacom did not work anymore, and i have to
> reboot the computer to make it work again.
>
> playing a bit more with that object made pd to crash.
>
> any suggestion to make my wacom work with hid?
> any other object that could get data from a wacom?
> or should i try to get the old sources of gemtablet to compile again???
>
> thanks
> Cyrille
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>


wacom-linux.pd
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd external that uses cocoa / objective C

[Rich E]

Hmmm, after hearing back from the Cocoa-dev mailing list that all of Cocoa's
Event handling code is based on Carbon (and is 64-bit compatible, at least
the Event Handling), I don't know if it is worth it to write the external in
ObjC (which I will probably do poorly at that, as it is my first attempt
with the language).  Anyways, Carbon is written in C, the WinTab API is
written in C, so introducing ObjC may turn out to be a hassle later on
instead of allowing future compatibility?

Well, thanks for the advice anyways.

On Mon, Dec 21, 2009 at 6:59 PM, Rich E  wrote:

> Thanks for the advice.  I am not sure I understand how to get the callback
> functions for pd to interface with the cocoa API, but I'll give a crack at
> it later tonight and see how far I get (first time doing anything in
> obj-c).  For me, I don't really care about elegance as much as that it will
> do everything that I want it to do (and fast).
>
> Rich
>
>
> On Mon, Dec 21, 2009 at 9:54 AM, IOhannes m zmoelnig wrote:
>
>> Rich E wrote:
>> > Hi all,
>> >
>> > I have been thinking of how to use cocoa in a pd external and I could
>> use
>> > some advice.  It has to be in Objective-C of course, and I see that
>> gridflow
>> > uses cocoa a little (format/quartz.m). Still, I am not understanding how
>> to
>> > combine the elements of a pd external (in C) with that of what I am
>> finding
>> > in cocoa example applications (in objective-c).  Will I just write the
>> > entire external in objective-c, or is there some specific way to use
>> obj-c
>> > syntax within a C source file?  Any tips or directs are thankfully
>> welcomed.
>>
>> you can mix C-code and ObjC-code just fine in your .m file (that is: you
>> can use C in ObjC; you cannot use ObjC in your C)
>>
>> so basically you write everything in ObjC, but the callback-functions
>> for Pd (which are written in C)
>> i guess there are more elegant ways to do it, but this is how i would do
>> it.
>>
>> fgmasdr
>> IOhannes
>>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd external that uses cocoa / objective C

[Rich E]

Thanks for the advice.  I am not sure I understand how to get the callback
functions for pd to interface with the cocoa API, but I'll give a crack at
it later tonight and see how far I get (first time doing anything in
obj-c).  For me, I don't really care about elegance as much as that it will
do everything that I want it to do (and fast).

Rich

On Mon, Dec 21, 2009 at 9:54 AM, IOhannes m zmoelnig wrote:

> Rich E wrote:
> > Hi all,
> >
> > I have been thinking of how to use cocoa in a pd external and I could use
> > some advice.  It has to be in Objective-C of course, and I see that
> gridflow
> > uses cocoa a little (format/quartz.m). Still, I am not understanding how
> to
> > combine the elements of a pd external (in C) with that of what I am
> finding
> > in cocoa example applications (in objective-c).  Will I just write the
> > entire external in objective-c, or is there some specific way to use
> obj-c
> > syntax within a C source file?  Any tips or directs are thankfully
> welcomed.
>
> you can mix C-code and ObjC-code just fine in your .m file (that is: you
> can use C in ObjC; you cannot use ObjC in your C)
>
> so basically you write everything in ObjC, but the callback-functions
> for Pd (which are written in C)
> i guess there are more elegant ways to do it, but this is how i would do
> it.
>
> fgmasdr
> IOhannes
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pd external that uses cocoa / objective C

[Rich E]

Hi all,

I have been thinking of how to use cocoa in a pd external and I could use
some advice.  It has to be in Objective-C of course, and I see that gridflow
uses cocoa a little (format/quartz.m). Still, I am not understanding how to
combine the elements of a pd external (in C) with that of what I am finding
in cocoa example applications (in objective-c).  Will I just write the
entire external in objective-c, or is there some specific way to use obj-c
syntax within a C source file?  Any tips or directs are thankfully welcomed.

regards,
rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] question about external free functions

[Rich E]

You have a point, pd crashing some time or another is inevitable, and even
'force quitting' the example app given to me by a the Wacom guys has the
same problem as I am dealing with - with one difference in that restarting
their app will reset the driver to its original state.  I must still be
missing something in my attempts.

One thing I still wonder about; why is shutting pd via Ctrl-q any different
than closing a patch (causing an exit() before destroying the patches)?
[closebang]'s won't work either, I suppose, among other things like what I
am trying to do.

On Sat, Dec 5, 2009 at 4:26 AM, Mathieu Bouchard  wrote:

> On Tue, 1 Dec 2009, Rich E wrote:
>
>  Okay, so Ctrl-Q skips all free functions on purpose.  If I am
>> understanding correctly, I need to register my cleanup function with atexit
>> on a function of type void _function_(void), but that means I don't have
>> access to any of my object's member variables.
>>
>
> one workaround is to make a global map where int is a dummy
> (unfortunately, void is not accepted as an argument of that type-pattern).
>
>
>  In the case of flext, the external class would need to be declared as
>> static in order for its destructor to be called before shutting down - do
>> you know if this is right, or possible, Thomas or anyone else knowing about
>> flext/C++ and pd?
>>
>
> This doesn't sound right. Note that there are some things that apply to
> objects that are directly global, and don't apply when the global variables
> are just pointers. I almost always use the latter because the former is a
> pain in the ass. (any static variable counts as global in this case, because
> they're essentially a kind of hidden global).
>
>
>  The reason I need this is because I am messing around with disconnecting
>> the wacom events from controlling the tablet, which takes some calls that
>> change the driver's settings.  If I cannot turn the settings back before the
>> program stops, they are permanently screwed until I restart the
>> driver/computer.  At least, this is all I can tell so far.
>>
>
> ow. so what can it do in case of segmentation fault or other crash of
> Pd?... what happens if you bang a naked [until] while you use your wacom
> thing?
>
>
>  _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] question about external free functions

[Rich E]

Okay, so Ctrl-Q skips all free functions on purpose.  If I am understanding
correctly, I need to register my cleanup function with atexit on a function
of type void _function_(void), but that means I don't have access to any of
my object's member variables.

In the case of flext, the external class would need to be declared as static
in order for its destructor to be called before shutting down - do you know
if this is right, or possible, Thomas or anyone else knowing about flext/C++
and pd?

The reason I need this is because I am messing around with disconnecting the
wacom events from controlling the tablet, which takes some calls that change
the driver's settings.  If I cannot turn the settings back before the
program stops, they are permanently screwed until I restart the
driver/computer.  At least, this is all I can tell so far.

Rich

On Sun, Nov 29, 2009 at 3:05 AM, Mathieu Bouchard wrote:

> On Sat, 28 Nov 2009, Rich E wrote:
>
>  Can anyone help me understand why an external's free function doesn't seem
>> to be called if pd is shut down as a whole (ex. ctrl-q)?  I put post's,
>> printf's, and breakpoints in my free function and they are called if I
>> remove the external from the patch or the patch as a whole (ex. ctrl-w).
>> But, if I shut down pd all at once, the breakpoint doesn't trigger and I
>> don't get any print.  The same thing happens in a flext external, within the
>> ~Destructor method. I don't understand.
>>
>
> because the exit() function always skips over all destructions except those
> mandated by atexit().
>
>  _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] question about external free functions

[Rich E]

Hi,

Can anyone help me understand why an external's free function doesn't seem
to be called if pd is shut down as a whole (ex. ctrl-q)?  I put post's,
printf's, and breakpoints in my free function and they are called if I
remove the external from the patch or the patch as a whole (ex. ctrl-w).
But, if I shut down pd all at once, the breakpoint doesn't trigger and I
don't get any print.  The same thing happens in a flext external, within the
~Destructor method. I don't understand.

Regards,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] multiple pd versions and settings on OS X

[Rich E]

Ah, perfect.  I get my cake and even get to eat it!  Thanks, Hans.

rich

On Wed, Nov 18, 2009 at 12:11 AM, Hans-Christoph Steiner wrote:

>
> On Mac OS X, you can stick a prefs plist into the Pd-extended.app and then
> it'll always ignore all other prefs.  Instead the Pd-extended.app, just copy
> /Applications/Pd-extended.app/Contents/org.puredata.pd.default.plist to
> /Applications/Pd-extended.app/Contents/org.puredata.pd.plist
>
> .hc
>
>
> On Nov 16, 2009, at 5:35 PM, Rich E wrote:
>
>  Hi,
>>
>> I've been using several different versions of pd in OS X: Pd-extended
>> (packaged), Pd-vanilla (packaged), and pd-gui-rewrite (compiled).  Every
>> time I use vanilla or gui-rewrite, I need to set and save the audio
>> settings, which writes a plist settings file to ~/Library/Preferences/.
>>  Then, when I start Pd-extended, it doesn't want to read the plist file
>> included with it, but reads this other 'local' one.
>>
>> It would be great if there was some way to tell pd which plist file to
>> load.  I see there is an option '-noprefs', how about an open '-prefs FILE'?
>>  I know you could do this with a bash script or something similar, but that
>> just seems messy for OS X.  I was working on this in python/ubuntu, but it
>> was always cumbersome at best.
>>
>> Rich
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>
>
> 
>
> Mistrust authority - promote decentralization.  - the hacker ethic
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling externals on snow leopard

[Rich E]

On Sat, Nov 14, 2009 at 7:30 PM, Rich E  wrote:

>
>
> On Sat, Nov 14, 2009 at 6:17 PM, Hans-Christoph Steiner wrote:
>
>>
>> On Nov 14, 2009, at 11:13 AM, Rich E wrote:
>>
>> Ran into problems right after starting the program... don't know why they
>> weren't there before, but..
>>
>> If I try running pd from /usr/local/bin via 'make install', I get the
>> following error:
>>
>> Error in startup script: couldn't read file
>> "/usr/local/lib/pd/bin/pd-gui.tcl": no such file or directory
>>
>> But the tcl file is there, don't know why it can't be found.
>>
>>
>> I just tried 'make install' on Mac OS X 10.5 and it worked fine for me.
>>  Both 'pd' alone and '/usr/local/bin/pd'
>>
>>
> Actually, "/usr/local/lib/pd/bin/pd-gui.tcl" is not there, but
> "/usr/local/bin/pd-gui.tcl" is. I think it is just getting installed to the
> wrong directory.
>
>
>> Portaudio is failing at startup (as I said before, there are still many
>> deprecation warnings as well, although it compiles):
>>
>> Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd
>>
>> ---pd-gui.tcl---
>> Pt_Start() called
>> Assertion failed: (sizeof( UInt32 ) == sizeof( long )), function
>> ringBufferIOProc, file src/hostapi/coreaudio/pa_mac_core.c, line 1722.
>> Pd: signal 6
>> closing audio...
>> Abort trap
>>
>> Apparently that function isn't 64bit :)
>>
>>
>> Seems like a portaudio bug, it would be good to report it there.
>>
>>
>
Reported.
>

After they give me a patch, the problem seemed to magically go away (pd
64bit is running on my system with portaudio/coreaudio).

Another question: even if I run "./pd -portaudio", I get the following
output:

ConnectPort: can't find mach server port name = jackdmp_entry.501_default
err = unknown error code
Cannot connect to server Mach port
jack server is not running or cannot be started
no message buffer overruns
JAR: jack server not running?



But then, pd starts with portaudio as the driver.  Why is there an attempt
to start jack if portaudio is specified?


Rich




>
>
>> Pd seems to work with Jack though, so I can test it through that (this is
>> how I normally run my patches in linux anyway).
>>
>> A question about settings:  where are they stored in OS X if I compile
>> from source?  I know Pd-extended works with the plist system, but how about
>> in the pd-gui-rewrite?
>>
>>
>> pd-gui-rewrite is roughly Pd-vanilla 0.43, so treat it accordingly.
>>
>> .hc
>>
>>
>
> One other thing, now when I try to run ./pd -jack, I get:
>
> Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd -jack
>
>
> ---pd-gui.tcl---
> Pt_Start() called
> jack_client_new: deprecated
> ERROR: 'pd' never showed up, 'pd-gui' quitting!
>
> I'd like to help more, but I seem to be spending alot of time hopelessly
> trying to get 64bit to work when I don't even see why 64bit is better than
> 32bit (in pd's case).
>
>
>> Rich
>>
>>
>> On Sat, Nov 14, 2009 at 4:35 PM, Rich E  wrote:
>>
>>> Portaudio makes now, 64bit pd.  I can also make the 32bit version using
>>> CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the
>>> following error:
>>>
>>> gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple
>>> -arch flags
>>> make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
>>>
>>> I was thinking, what happens when you have a universal binary pd and you
>>> mix external types, like some are 32bit and some are 64bit?  Maybe a
>>> universal binary pd isn't so good..
>>>
>>> I'll try testing out the 64bit pd-gui-rewrite for a while, see if
>>> anything strange happens.
>>>
>>>
>>> On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner 
>>> wrote:
>>>
>>>>
>>>> Ok, I updated the portaudio to the latest, updated 3 weeks ago in
>>>> portaudio SVN.  Plus I fixed your CFLAGS bug.  You should also be able to
>>>> build universal by doing "./configure --enable-universal" instead of
>>>> manually setting the CFLAGS/LDFLAGS.
>>>>
>>>> .hc
>>>>
>>>> On Nov 13, 2009, at 2:03 PM, Rich E wrote:
>>>>
>>>> I 

Re: [PD] [GEM] OS X How to compile against SDK 10.5 in os x 10.6

[Rich E]

Anyone have more suggestions as how to get this compiling on Snow Leopard?
It is making it impossible to build pd extended, which I would like to do in
order to add debug flags.

Rich

On Thu, Nov 12, 2009 at 12:51 AM, Jaime Oliver wrote:

> I thought I had sent this already, but just saw it in my drafts...:
>
> I use capital letters to distinguish what I'm writing form what the
> computer printed:
>
> ///
> NORMAL STUFF:
> ///
>
> Jaime-Olivers-MacBook-Pro:src joliverl$ aclocal
> Jaime-Olivers-MacBook-Pro:src joliverl$ autoconf
>
> ///
> THIS IS THE ./configure OUTPUT:
> ///
>
> Jaime-Olivers-MacBook-Pro:src joliverl$ ./configure
> --with-pd=/Applications/Pd-0.42-5.app/Contents/Resources/
> checking for g++... g++
> checking for C++ compiler default output file name... a.out
> checking whether the C++ compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether ln -s works... yes
> checking whether compiler accepts "-fPIC"... yes
> building Gem with Controls-objects
> building Gem with Geos-objects
> building Gem with Manips-objects
> building Gem with Nongeos-objects
> building Gem with Particles-objects
> building Gem with Pixes-objects
> building Gem with openGL-objects
> building Gem without Vertex-objects
> checking for sin in -lm... yes
> checking for main in -lz... yes
> checking for dlopen in -ldl... yes
> checking how to run the C++ preprocessor... g++ -E
> checking for X... disabled
> checking for "OpenGL"-framework... yes
> checking for "AGL"-framework... yes
> checking for main in -lstdc++... yes
> checking for "Carbon"-framework... yes
> checking for "QuickTime"-framework... yes
> checking for pkg-config... no
> checking for PKG_IMAGEMAGICK___CFLAGS...
> checking for PKG_IMAGEMAGICK___LIBS...
> checking for ImageMagick++-config... no
> checking for main in -lMagick++... no
> checking for PKG_TIFF_CFLAGS...
> checking for PKG_TIFF_LIBS...
> checking for tiff-config... no
> checking for TIFFOpen in -ltiff... no
> checking for PKG_JPEG_CFLAGS...
> checking for PKG_JPEG_LIBS...
> checking for jpeg-config... no
> checking for jpeg_read_header in -ljpeg... no
> checking for PKG_GMERLIN_AVDEC_CFLAGS...
> checking for PKG_GMERLIN_AVDEC_LIBS...
> checking for gmerlin_avdec-config... no
> checking for gavl_start in -lgmerlin_avdec... no
> checking for PKG_LIBMPEG3_CFLAGS...
> checking for PKG_LIBMPEG3_LIBS...
> checking for libmpeg3-config... no
> checking for mpeg3_check_sig in -lmpeg3... no
> checking for PKG_MPEG_CFLAGS...
> checking for PKG_MPEG_LIBS...
> checking for mpeg-config... no
> checking for OpenMPEG in -lmpeg... no
> checking for PKG_AVIFILE_CFLAGS...
> checking for PKG_AVIFILE_LIBS...
> checking for avifile-config... no
> checking for CreateIAviReadFile in -laviplay... no
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking linux/videodev.h usability... no
> checking linux/videodev.h presence... no
> checking for linux/videodev.h... no
> checking for PKG_LIBV4L1_CFLAGS...
> checking for PKG_LIBV4L1_LIBS...
> checking for libv4l1-config... no
> checking for v4l1_open in -lv4l1... no
> checking for PKG_LIBV4L2_CFLAGS...
> checking for PKG_LIBV4L2_LIBS...
> checking for libv4l2-config... no
> checking for v4l2_open in -lv4l2... no
> checking for PKG_IEEE1394_CFLAGS...
> checking for PKG_IEEE1394_LIBS...
> checking for ieee1394-config... no
> checking for main in -ldv... no
> checking for PKG_FTGL_CFLAGS...
> checking for PKG_FTGL_LIBS...
> checking for ftgl-config... no
> checking for main in -lftgl... no
> checking FTGL/ftgl.h usability... no
> checking FTGL/ftgl.h presence... no
> checking for FTGL/ftgl.h... no
> checking for PKG_ARTOOLKIT_CFLAGS...
> checking for PKG_ARTOOLKIT_LIBS...
> checking for artoolkit-config... no
> checking for arInitCparam in -lAR... no
> checking for pthread_create in -lpthread... yes
> checking for X... disabled
> checking for ANSI C header files... (cached) yes
> checking fcntl.h usability... yes
> checking fcntl.h presence... yes
> checking for fcntl.h... yes
> checking float.h usability... yes
> checking float.h presence... yes
> checking for floa

Re: [PD] how to tell if pd is in the background/foreground

[Rich E]

I think [active] will tell you if the current patch is in the foreground or
background, but I needed something a little deeper.  Actually, a guy from
the wacom developer team sent me some example code on how to do this at an
'AppleEvents' level and I already have a wacom object of os x how I need it
(disconnected from the cursor, even when pd is in the background).
Supposedly this "isn't nice" to other apps, but hey, pd is more important
than them anyway :)

cheers,
Rich

On Tue, Nov 17, 2009 at 1:49 AM, PSPunch  wrote:

>
> Hi Rich,
>
> I maybe misunderstanding, but maybe [active] or its source code may help
> you.
>
> --
> David Shimamoto
>
>
>  Hi all,
>>
>> Anyone know how to tell (on OS X) if pd is in the background or foreground
>> from C?  I'm messing with Thomas' [wacom] external, trying to get it to keep
>> the tablet disconnected from the cursor, but it resets every time pd goes to
>> background.  So, if I can figure out from the external when pd goes back to
>> the foreground, I can reset it there, at least.
>>
>> regards,
>> Rich
>>
>>
>> 
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] multiple pd versions and settings on OS X

[Rich E]

Hi,

I've been using several different versions of pd in OS X: Pd-extended
(packaged), Pd-vanilla (packaged), and pd-gui-rewrite (compiled).  Every
time I use vanilla or gui-rewrite, I need to set and save the audio
settings, which writes a plist settings file to ~/Library/Preferences/.
Then, when I start Pd-extended, it doesn't want to read the plist file
included with it, but reads this other 'local' one.

It would be great if there was some way to tell pd which plist file to
load.  I see there is an option '-noprefs', how about an open '-prefs
FILE'?  I know you could do this with a bash script or something similar,
but that just seems messy for OS X.  I was working on this in python/ubuntu,
but it was always cumbersome at best.

Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-gui-rewrite testing

[Rich E]

Just found another bug after opening the 'test audio and midi" patch,
closing it, and attempting to reopen it:

invalid command name "menu_raisenextwindow"
invalid command name "menu_raisenextwindow"
while executing
"menu_raisenextwindow"
(command bound to event)


I also get this when trying to open the 'Load Meter' patch, or any other
patch via 'open'.  Trying to close pd and reopen gives:

ERROR: 'pd' never showed up, 'pd-gui' quitting!




On Mon, Nov 16, 2009 at 7:55 PM, Rich E  wrote:

> Hi List, Hans,
>
> I've been using the pd-gui-rewrite-0.43 svn for a couple days now and here
> are some notes I've taken when finding various bugs (is the better sent to
> the pd-dev list?):
>
> • In Audio Settings, the text in the drop down menus is hardly visible
> because it is very light grey
> • there is a new menu item called 'apple' with "about pd" and preferences"
> • editing an object name:
> ‣ moving with arrows adds a space to the end, but does not move within the
> object name
> • opening "about pd" gives an error:
> ‣ Error: can't read "pd_myversion": no such variable"
> ‣ an't read "pd_myversion": no such variable
> can't read "pd_myversion": no such variable
> while executing
> "regsub -all PD_VERSION $bigstring2 $pd_myversion bigstring3"
> (procedure "::pd_menucommands::menu_opentext" line 15)
> invoked from within
> "::pd_menucommands::menu_opentext "$dirname/$basename""
> (".txt" arm line 1)
> invoked from within
> "switch -- [string tolower [file extension $basename]] {
> ".txt"{::pd_menucommands::menu_opentext "$dirname/$basename"
> } ".c"{::..."
> (procedure "menu_doc_open" line 4)
> invoked from within
> "menu_doc_open doc/1.manual 1.introduction.txt"
> (menu invoke)
>
>
> I have some time on my hands now that I finished my Master's, and frankly I
> think the pd-vanilla GUI is unpleasant, so I could learn tcl/tk and help
> out, if needed.
>
> rich
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pd-gui-rewrite testing

[Rich E]

Hi List, Hans,

I've been using the pd-gui-rewrite-0.43 svn for a couple days now and here
are some notes I've taken when finding various bugs (is the better sent to
the pd-dev list?):

• In Audio Settings, the text in the drop down menus is hardly visible
because it is very light grey
• there is a new menu item called 'apple' with "about pd" and preferences"
• editing an object name:
‣ moving with arrows adds a space to the end, but does not move within the
object name
• opening "about pd" gives an error:
‣ Error: can't read "pd_myversion": no such variable"
‣ an't read "pd_myversion": no such variable
can't read "pd_myversion": no such variable
while executing
"regsub -all PD_VERSION $bigstring2 $pd_myversion bigstring3"
(procedure "::pd_menucommands::menu_opentext" line 15)
invoked from within
"::pd_menucommands::menu_opentext "$dirname/$basename""
(".txt" arm line 1)
invoked from within
"switch -- [string tolower [file extension $basename]] {
".txt"{::pd_menucommands::menu_opentext "$dirname/$basename"
} ".c"{::..."
(procedure "menu_doc_open" line 4)
invoked from within
"menu_doc_open doc/1.manual 1.introduction.txt"
(menu invoke)


I have some time on my hands now that I finished my Master's, and frankly I
think the pd-vanilla GUI is unpleasant, so I could learn tcl/tk and help
out, if needed.

rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] running Pd-extended from terminal in OS X

[Rich E]

2009/11/15 IOhannes m zmölnig 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Max wrote:
> > Doesn't work here (OS 10.6) neither with Pd-extended (0.41.4), but with
> PD vanilla 0.42-5 it does work.
>
> this is a known bug in pd-0.41 fixed in 0.42
>
> the problem is the way Pd is started on osx in order to make it a nice
> and proper osx app, the "main" application has to be the GUI.
> so when you start Pd from terminal, it will actually not start but
> instead launch Pd-gui which fires up Pd (this time for real).
> since this is so complicated, all arguments get lost.
>
> however, you should be able to do:
> /Applications/Pd-extended.app/Contents/Resources/bin/pd -nogui
> ~/pd/externals/incr/incr-help.pd
>
>
That probably works, but who knows since you can't see the patch :)

Ok, good to know it is already fixed and thanks for pointing that out.



> fgmsd
> IOhannes
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAksAfl4ACgkQkX2Xpv6ydvRA0wCg6R96nVVVlN0VvPI4j72rcc+x
> QTwAn23/+BdF+oHj+/pjrm6TNkE50oH/
> =XRG2
> -END PGP SIGNATURE-
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] running Pd-extended from terminal in OS X

[Rich E]

If you try using pd-vanilla, it works (for me at least).  Actually, i'm
using pd-gui-rewrite, but I suppose nothing has changed in that concerning
command-line argument parsing.

On Sun, Nov 15, 2009 at 9:31 PM, Max  wrote:

> Doesn't work here (OS 10.6) neither with Pd-extended (0.41.4), but with PD
> vanilla 0.42-5 it does work.
>
> Am 15.11.2009 um 21:16 schrieb Derek Holzer:
>
> > You're right, doesn't work here either, using either "open" or "-open"
> flag, with explicit pathnames and all.
> >
> > D.
> >
> > Rich E wrote:
> >> I can't seem to open patches from the terminal in OS X (with
> pd-extended, the second command works with vanilla).  I try either:
> >> /Applications/Pd-extended.app/Contents/Resources/bin/pd
> ~/pd/externals/incr/incr-help.pd
> >> /Applications/Pd-extended.app/Contents/Resources/bin/pd -open
> ~/pd/externals/incr/incr-help.pd
> >> without success.
> >
> > --
> > ::: derek holzer ::: http://blog.myspace.com/macumbista :::
> http://www.vimeo.com/macumbista :::
> > ---Oblique Strategy # 100:
> > "It is quite possible"
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] running Pd-extended from terminal in OS X

[Rich E]

I can't seem to open patches from the terminal in OS X (with pd-extended,
the second command works with vanilla).  I try either:

/Applications/Pd-extended.app/Contents/Resources/bin/pd
~/pd/externals/incr/incr-help.pd
/Applications/Pd-extended.app/Contents/Resources/bin/pd -open
~/pd/externals/incr/incr-help.pd

without success.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] how to tell if pd is in the background/foreground

[Rich E]

Hi all,

Anyone know how to tell (on OS X) if pd is in the background or foreground
from C?  I'm messing with Thomas' [wacom] external, trying to get it to keep
the tablet disconnected from the cursor, but it resets every time pd goes to
background.  So, if I can figure out from the external when pd goes back to
the foreground, I can reset it there, at least.

regards,
Rich
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max4Live... How about Pd4Live?

[Rich E]

On Sat, Nov 14, 2009 at 1:18 PM, João Pais  wrote:

> I think you can all forget pd4live. after all, it's a commercial company.
> When I asked Gerhard about it (a bit as a joke because I knew the answer),
> he replied something like BLAHGRGAHGAGGGRRG!
>
> which doesn't mean that a not-so-deep-but-similar integration can be made,
> using osc, jack, or whatever you can do (never worked with Live). or between
> pd and another program, and still get the same result. or program the live
> part in pd, and you'll have pd4pd.
>
>
Yea, tried that, there went about 2 years using a buggy, ugly, awkward
sequencer for doing standard rhythmic stuff, instead of just using a
tried-and-true piece of software.  I constantly had to stop thinking about
music in order to fix my pd sequencer, or add some common feature. Live is
really put together well, so many things that you take for granted until you
actually try to implement something similar yourself.  I'm not saying it
does everything or even close, but it does the simple stuff really well and
saves the end-user/programmer from having to worry about it.


>
>
>  To Michal:
>> i see your point on the "openness", and thanks for that link. i doubt
>> Ableton will release it's source code, at least until they figure out how
>> to
>> "open Live", as Gerhard mentioned, and still have enough income for 100
>> employees. It'll be a good day when Live users will be able to customize
>> it's GUI as necessary. As far as Pluggo goes, it has been discontinued but
>> reappears in Max4Live :o, .
>>
>> To Hans:
>> Jack is definitely a great tool but, like i said, i don't know how it
>> handles midi, or how about OSC? i have to read more on the subject before
>> i
>> can have an actual opinion.
>>
>> To justin:
>> Can ardour be customized as a performance tool (which is abletons key
>> feature IMO)
>>
>> Thanks for your input, fellas.
>>
>> Jeff
>>
>
>
> --
> Friedenstr. 58
> 10249 Berlin (Deutschland)
> Tel +49 30 42020091 | Mob +49 162 6843570
> Studio +49 30 69509190
> jmmmp...@googlemail.com | skype: jmmmpjmmmp
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling externals on snow leopard

[Rich E]

My system doesn't want to compile for ppc64 (I have no idea what type of mac
needs this):

macosx-version-min=10.5 -c porttime/ptmacosx_cf.c  -fno-common -DPIC -o
.libs/ptmacosx_cf.o
In file included from /usr/include/mach/mach_interface.h:50,
 from /usr/include/mach/mach.h:67,
 from porttime/ptmacosx_cf.c:8:
/usr/include/mach/task.h:35:29: error: mach/ppc64/task.h: No such file or
directory
In file included from /usr/include/mach/mach_interface.h:51,
 from /usr/include/mach/mach.h:67,
 from porttime/ptmacosx_cf.c:8:
/usr/include/mach/thread_act.h:35:35: error: mach/ppc64/thread_act.h: No
such file or directory
lipo: can't figure out the architecture type of:
/var/folders/mi/miOJDQB4G4W+2Le0+GFkPk+++TI/-Tmp-//ccEWxRNK.out
make[2]: *** [ptmacosx_cf.lo] Error 1




On Sat, Nov 14, 2009 at 6:10 PM, Hans-Christoph Steiner wrote:

>
> I forgot.  In order to build a Universal, you need to include 
> --disable-dependency-tracking.
>  So like this:
>
> ./configure --disable-dependency-tracking --enable-universal
>
> My guess is that a universal Pd running in 64-bit mode will fail to load a
> 32-bit external.
>
> .hc
>
> On Nov 14, 2009, at 10:35 AM, Rich E wrote:
>
> Portaudio makes now, 64bit pd.  I can also make the 32bit version using
> CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the
> following error:
>
> gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple
> -arch flags
> make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
>
> I was thinking, what happens when you have a universal binary pd and you
> mix external types, like some are 32bit and some are 64bit?  Maybe a
> universal binary pd isn't so good..
>
> I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything
> strange happens.
>
> On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner wrote:
>
>>
>> Ok, I updated the portaudio to the latest, updated 3 weeks ago in
>> portaudio SVN.  Plus I fixed your CFLAGS bug.  You should also be able to
>> build universal by doing "./configure --enable-universal" instead of
>> manually setting the CFLAGS/LDFLAGS.
>>
>> .hc
>>
>> On Nov 13, 2009, at 2:03 PM, Rich E wrote:
>>
>> I compiled the pd-gui-rewrite branch today as 64bit with portaudio
>> support, but haven't tested it much.
>>
>> To compile portaudio as 64bit, you need the the sources from their svn.
>> If I try to compile using the sources included with pd, I get a bunch of
>> deprecation warnings followed by a syntax error.  If I update the source
>> codes to those in portaudio's svn trunk, the syntax error goes away but
>> there are still many deprecation warnings.  But, I have audio, with and
>> without jack.
>>
>> The configure script doesn't like it when I do:
>> export CFLAGS="-arch i386 -arch x86_64"
>> export LDFLAGS="-arch i386 -arch x86_64"
>>
>> This is how I compiled portaudio, but when I do it with pd, the configure
>> script reports gcc as unusable.  Is there a better way to make gcc compile
>> universal binaries?
>>
>> Rich
>>
>> On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner wrote:
>>
>>>
>>> portaudio provides CoreAudio support already.  It is AudioUnit support
>>> that is in the works, which I suppose is part of CoreAudio.  What are the
>>> errors with portaudio in pd-gui-rewrite?  It would be good to get those
>>> fixed there, since you said that portaudio on its own can build fine for
>>> 64-bit (or am I mistaken?)
>>>
>>> .hc
>>>
>>> On Nov 11, 2009, at 8:21 PM, Rich E wrote:
>>>
>>> Got it compiled and it looks nice.  The portaudio failed, same as
>>> Pd-Vanilla, but I guess you aren't worried about that because you are
>>> working on getting coreaudio support (which would be nice).  Jack works,
>>> everything is sounds nice and stable.
>>>
>>> The only thing I noticed is that expr cannot be found.  I have only tried
>>> a few of the example patches so far.
>>>
>>> cheers,
>>> Rich
>>>
>>> On Thu, Nov 12, 2009 at 1:57 AM, Rich E  wrote:
>>>
>>>> Oops, my fault.  I had some residual CFLAGS from trying to get Gem to
>>>> compile... onward :)
>>>>
>>>> On Thu, Nov 12, 2009 at 1:23 AM, Rich E  wrote:
>>>>
>>>>> On running a regular ./configure in the gui rewrite branch, I get the
>>>>> error:
>>>>>
>>>>> che

Re: [PD] compiling externals on snow leopard

[Rich E]

On Sat, Nov 14, 2009 at 6:17 PM, Hans-Christoph Steiner wrote:

>
> On Nov 14, 2009, at 11:13 AM, Rich E wrote:
>
> Ran into problems right after starting the program... don't know why they
> weren't there before, but..
>
> If I try running pd from /usr/local/bin via 'make install', I get the
> following error:
>
> Error in startup script: couldn't read file
> "/usr/local/lib/pd/bin/pd-gui.tcl": no such file or directory
>
> But the tcl file is there, don't know why it can't be found.
>
>
> I just tried 'make install' on Mac OS X 10.5 and it worked fine for me.
>  Both 'pd' alone and '/usr/local/bin/pd'
>
>
Actually, "/usr/local/lib/pd/bin/pd-gui.tcl" is not there, but
"/usr/local/bin/pd-gui.tcl" is. I think it is just getting installed to the
wrong directory.


> Portaudio is failing at startup (as I said before, there are still many
> deprecation warnings as well, although it compiles):
>
> Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd
>
> ---pd-gui.tcl---
> Pt_Start() called
> Assertion failed: (sizeof( UInt32 ) == sizeof( long )), function
> ringBufferIOProc, file src/hostapi/coreaudio/pa_mac_core.c, line 1722.
> Pd: signal 6
> closing audio...
> Abort trap
>
> Apparently that function isn't 64bit :)
>
>
> Seems like a portaudio bug, it would be good to report it there.
>
>
Reported.


> Pd seems to work with Jack though, so I can test it through that (this is
> how I normally run my patches in linux anyway).
>
> A question about settings:  where are they stored in OS X if I compile from
> source?  I know Pd-extended works with the plist system, but how about in
> the pd-gui-rewrite?
>
>
> pd-gui-rewrite is roughly Pd-vanilla 0.43, so treat it accordingly.
>
> .hc
>
>

One other thing, now when I try to run ./pd -jack, I get:

Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd -jack
---pd-gui.tcl---
Pt_Start() called
jack_client_new: deprecated
ERROR: 'pd' never showed up, 'pd-gui' quitting!

I'd like to help more, but I seem to be spending alot of time hopelessly
trying to get 64bit to work when I don't even see why 64bit is better than
32bit (in pd's case).


> Rich
>
>
> On Sat, Nov 14, 2009 at 4:35 PM, Rich E  wrote:
>
>> Portaudio makes now, 64bit pd.  I can also make the 32bit version using
>> CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the
>> following error:
>>
>> gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple
>> -arch flags
>> make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
>>
>> I was thinking, what happens when you have a universal binary pd and you
>> mix external types, like some are 32bit and some are 64bit?  Maybe a
>> universal binary pd isn't so good..
>>
>> I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything
>> strange happens.
>>
>>
>> On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner wrote:
>>
>>>
>>> Ok, I updated the portaudio to the latest, updated 3 weeks ago in
>>> portaudio SVN.  Plus I fixed your CFLAGS bug.  You should also be able to
>>> build universal by doing "./configure --enable-universal" instead of
>>> manually setting the CFLAGS/LDFLAGS.
>>>
>>> .hc
>>>
>>> On Nov 13, 2009, at 2:03 PM, Rich E wrote:
>>>
>>> I compiled the pd-gui-rewrite branch today as 64bit with portaudio
>>> support, but haven't tested it much.
>>>
>>> To compile portaudio as 64bit, you need the the sources from their svn.
>>> If I try to compile using the sources included with pd, I get a bunch of
>>> deprecation warnings followed by a syntax error.  If I update the source
>>> codes to those in portaudio's svn trunk, the syntax error goes away but
>>> there are still many deprecation warnings.  But, I have audio, with and
>>> without jack.
>>>
>>> The configure script doesn't like it when I do:
>>> export CFLAGS="-arch i386 -arch x86_64"
>>> export LDFLAGS="-arch i386 -arch x86_64"
>>>
>>> This is how I compiled portaudio, but when I do it with pd, the configure
>>> script reports gcc as unusable.  Is there a better way to make gcc compile
>>> universal binaries?
>>>
>>> Rich
>>>
>>> On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner 
>>

Re: [PD] Max4Live... How about Pd4Live?

[Rich E]

The thing that impressed me the most about Max4Live (haven't tried it, just
seen some videos) is that you can receive parameter changes of Live's
controls within Max and you can send parameter changes to just about
everything from Max to Live.  So, you can have one automation control
another, or have resizing one sample trigger a different control, etc.
Sequencers don't have to control midi in the Max patch, they can control
anything you route it to.

I tried doing this many different ways using Pd/Ardour, but I always found
it too cumbersome and just recorded audio instead of automation.  This is
very limiting if you want to re-use automation recordings.  It is of course
possible with Pd/Ardour and Midi, just very cumbersome and bug-prone.

I suppose having Pd directly in Live would only be slightly easier than
directing Pd through Jack and into Live (by the way, where did the Jack-VST
plug-in go?? I've been looking for this and it is not included in the
jackosx package) and you wouldn't get all the interface controls that
Ableton gave to Max.  I do remember hearing about a Live/python SDK, so if
you could make a patch that gave access to those controls, I can see it
being just as powerful, but without all the nice GUI objects that Max has.

Rich

On Sat, Nov 14, 2009 at 4:41 AM, Justin Glenn Smith wrote:

> Jeffrey Concepcion wrote:
> ...
>
> > To justin:
> > Can ardour be customized as a performance tool (which is abletons key
> > feature IMO)
> >
>
> No need for customization to use it that way, actually. It does not have
> the range of features that ableton live has, but I have used it successfuly
> as a source of realtime tweaked automations  / a virtual mixing board /
> loop
> recorder and player.
>
> One thing it has that in my knowledge actually exceeds what ableton offers
> is the versatility of the way buses / tracks can be inter-routed. Any
> number
> of tracks and buses can be mixed into the input of any others (each track
> and
> bus of course having configurable pre / post effects), without the
> artificial
> limits that I have seen with ableton live.
>
> I made a set of ladspa plugins a while back to allow controling puredata
> parameters from ardour automations, it has some definite limitations
> usability
> wise but it is available from
> http://code.google.com/p/noisesmith-linux-audio/
> or direct download my last (but not very recent) version from
> http://noisesmith-linux-audio.googlecode.com/files/ladosc.tar.bz2
>
> It uses osc to send the parameter data so the ardour and pd processes can
> be
> running on two different machines.
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling externals on snow leopard

[Rich E]

Portaudio makes now, 64bit pd.  I can also make the 32bit version using
CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the
following error:

gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple
-arch flags
make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1

I was thinking, what happens when you have a universal binary pd and you mix
external types, like some are 32bit and some are 64bit?  Maybe a universal
binary pd isn't so good..

I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything
strange happens.

On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner wrote:

>
> Ok, I updated the portaudio to the latest, updated 3 weeks ago in portaudio
> SVN.  Plus I fixed your CFLAGS bug.  You should also be able to build
> universal by doing "./configure --enable-universal" instead of manually
> setting the CFLAGS/LDFLAGS.
>
> .hc
>
> On Nov 13, 2009, at 2:03 PM, Rich E wrote:
>
> I compiled the pd-gui-rewrite branch today as 64bit with portaudio support,
> but haven't tested it much.
>
> To compile portaudio as 64bit, you need the the sources from their svn.  If
> I try to compile using the sources included with pd, I get a bunch of
> deprecation warnings followed by a syntax error.  If I update the source
> codes to those in portaudio's svn trunk, the syntax error goes away but
> there are still many deprecation warnings.  But, I have audio, with and
> without jack.
>
> The configure script doesn't like it when I do:
> export CFLAGS="-arch i386 -arch x86_64"
> export LDFLAGS="-arch i386 -arch x86_64"
>
> This is how I compiled portaudio, but when I do it with pd, the configure
> script reports gcc as unusable.  Is there a better way to make gcc compile
> universal binaries?
>
> Rich
>
> On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner wrote:
>
>>
>> portaudio provides CoreAudio support already.  It is AudioUnit support
>> that is in the works, which I suppose is part of CoreAudio.  What are the
>> errors with portaudio in pd-gui-rewrite?  It would be good to get those
>> fixed there, since you said that portaudio on its own can build fine for
>> 64-bit (or am I mistaken?)
>>
>> .hc
>>
>> On Nov 11, 2009, at 8:21 PM, Rich E wrote:
>>
>> Got it compiled and it looks nice.  The portaudio failed, same as
>> Pd-Vanilla, but I guess you aren't worried about that because you are
>> working on getting coreaudio support (which would be nice).  Jack works,
>> everything is sounds nice and stable.
>>
>> The only thing I noticed is that expr cannot be found.  I have only tried
>> a few of the example patches so far.
>>
>> cheers,
>> Rich
>>
>> On Thu, Nov 12, 2009 at 1:57 AM, Rich E  wrote:
>>
>>> Oops, my fault.  I had some residual CFLAGS from trying to get Gem to
>>> compile... onward :)
>>>
>>> On Thu, Nov 12, 2009 at 1:23 AM, Rich E  wrote:
>>>
>>>> On running a regular ./configure in the gui rewrite branch, I get the
>>>> error:
>>>>
>>>> checking for C compiler default output file name...
>>>> configure: error: in
>>>> `/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43':
>>>> configure: error: C compiler cannot create executables
>>>> See `config.log' for more details.
>>>>
>>>> I attached the config.log, any ideas?
>>>>
>>>> Rich
>>>>
>>>>
>>>>  On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner <
>>>> h...@at.or.at> wrote:
>>>>
>>>>>
>>>>> The build system in vanilla/extended is pretty ugly, especially for Mac
>>>>> OS X.  The build system in the pd-gui-rewrite/0.43 branch has been 
>>>>> rewritten
>>>>> from scratch to be a full autotools build system.  That should fix the
>>>>> -isysroot and --disable-portaudio problem you mention.  Try it out, and we
>>>>> can fix any issues there.
>>>>>
>>>>> svn co
>>>>> https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewrite/0.43/
>>>>> cd 0.43
>>>>> ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
>>>>>
>>>>> .hc
>>>>>
>>>>> On Nov 11, 2009, at 6:08 PM, Rich E wrote:
>>>>>
>>>>> Oops, I accidentally just sent my last post to Hans.  Please read this
>>>>> and the post below...

Re: [PD] compiling externals on snow leopard

[Rich E]

Ran into problems right after starting the program... don't know why they
weren't there before, but..

If I try running pd from /usr/local/bin via 'make install', I get the
following error:

Error in startup script: couldn't read file
"/usr/local/lib/pd/bin/pd-gui.tcl": no such file or directory

But the tcl file is there, don't know why it can't be found.

Portaudio is failing at startup (as I said before, there are still many
deprecation warnings as well, although it compiles):

Richard-Eakins-MacBook-Pro:src richardeakin$ ./pd
---pd-gui.tcl---
Pt_Start() called
Assertion failed: (sizeof( UInt32 ) == sizeof( long )), function
ringBufferIOProc, file src/hostapi/coreaudio/pa_mac_core.c, line 1722.
Pd: signal 6
closing audio...
Abort trap

Apparently that function isn't 64bit :)

Pd seems to work with Jack though, so I can test it through that (this is
how I normally run my patches in linux anyway).

A question about settings:  where are they stored in OS X if I compile from
source?  I know Pd-extended works with the plist system, but how about in
the pd-gui-rewrite?

Rich


On Sat, Nov 14, 2009 at 4:35 PM, Rich E  wrote:

> Portaudio makes now, 64bit pd.  I can also make the 32bit version using
> CFLAGS and LDFLAGS, but the --enable-universal doesn't work because of the
> following error:
>
> gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple
> -arch flags
> make[2]: *** [libportaudio_la-pa_allocation.lo] Error 1
>
> I was thinking, what happens when you have a universal binary pd and you
> mix external types, like some are 32bit and some are 64bit?  Maybe a
> universal binary pd isn't so good..
>
> I'll try testing out the 64bit pd-gui-rewrite for a while, see if anything
> strange happens.
>
>
> On Sat, Nov 14, 2009 at 6:42 AM, Hans-Christoph Steiner wrote:
>
>>
>> Ok, I updated the portaudio to the latest, updated 3 weeks ago in
>> portaudio SVN.  Plus I fixed your CFLAGS bug.  You should also be able to
>> build universal by doing "./configure --enable-universal" instead of
>> manually setting the CFLAGS/LDFLAGS.
>>
>> .hc
>>
>> On Nov 13, 2009, at 2:03 PM, Rich E wrote:
>>
>> I compiled the pd-gui-rewrite branch today as 64bit with portaudio
>> support, but haven't tested it much.
>>
>> To compile portaudio as 64bit, you need the the sources from their svn.
>> If I try to compile using the sources included with pd, I get a bunch of
>> deprecation warnings followed by a syntax error.  If I update the source
>> codes to those in portaudio's svn trunk, the syntax error goes away but
>> there are still many deprecation warnings.  But, I have audio, with and
>> without jack.
>>
>> The configure script doesn't like it when I do:
>> export CFLAGS="-arch i386 -arch x86_64"
>> export LDFLAGS="-arch i386 -arch x86_64"
>>
>> This is how I compiled portaudio, but when I do it with pd, the configure
>> script reports gcc as unusable.  Is there a better way to make gcc compile
>> universal binaries?
>>
>> Rich
>>
>> On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner wrote:
>>
>>>
>>> portaudio provides CoreAudio support already.  It is AudioUnit support
>>> that is in the works, which I suppose is part of CoreAudio.  What are the
>>> errors with portaudio in pd-gui-rewrite?  It would be good to get those
>>> fixed there, since you said that portaudio on its own can build fine for
>>> 64-bit (or am I mistaken?)
>>>
>>> .hc
>>>
>>> On Nov 11, 2009, at 8:21 PM, Rich E wrote:
>>>
>>> Got it compiled and it looks nice.  The portaudio failed, same as
>>> Pd-Vanilla, but I guess you aren't worried about that because you are
>>> working on getting coreaudio support (which would be nice).  Jack works,
>>> everything is sounds nice and stable.
>>>
>>> The only thing I noticed is that expr cannot be found.  I have only tried
>>> a few of the example patches so far.
>>>
>>> cheers,
>>> Rich
>>>
>>> On Thu, Nov 12, 2009 at 1:57 AM, Rich E  wrote:
>>>
>>>> Oops, my fault.  I had some residual CFLAGS from trying to get Gem to
>>>> compile... onward :)
>>>>
>>>> On Thu, Nov 12, 2009 at 1:23 AM, Rich E  wrote:
>>>>
>>>>> On running a regular ./configure in the gui rewrite branch, I get the
>>>>> error:
>>>>>
>>>>> checking for C compiler default output fil

Re: [PD] compiling externals on snow leopard

[Rich E]

I compiled the pd-gui-rewrite branch today as 64bit with portaudio support,
but haven't tested it much.

To compile portaudio as 64bit, you need the the sources from their svn.  If
I try to compile using the sources included with pd, I get a bunch of
deprecation warnings followed by a syntax error.  If I update the source
codes to those in portaudio's svn trunk, the syntax error goes away but
there are still many deprecation warnings.  But, I have audio, with and
without jack.

The configure script doesn't like it when I do:
export CFLAGS="-arch i386 -arch x86_64"
export LDFLAGS="-arch i386 -arch x86_64"

This is how I compiled portaudio, but when I do it with pd, the configure
script reports gcc as unusable.  Is there a better way to make gcc compile
universal binaries?

Rich

On Thu, Nov 12, 2009 at 5:15 PM, Hans-Christoph Steiner wrote:

>
> portaudio provides CoreAudio support already.  It is AudioUnit support that
> is in the works, which I suppose is part of CoreAudio.  What are the errors
> with portaudio in pd-gui-rewrite?  It would be good to get those fixed
> there, since you said that portaudio on its own can build fine for 64-bit
> (or am I mistaken?)
>
> .hc
>
> On Nov 11, 2009, at 8:21 PM, Rich E wrote:
>
> Got it compiled and it looks nice.  The portaudio failed, same as
> Pd-Vanilla, but I guess you aren't worried about that because you are
> working on getting coreaudio support (which would be nice).  Jack works,
> everything is sounds nice and stable.
>
> The only thing I noticed is that expr cannot be found.  I have only tried a
> few of the example patches so far.
>
> cheers,
> Rich
>
> On Thu, Nov 12, 2009 at 1:57 AM, Rich E  wrote:
>
>> Oops, my fault.  I had some residual CFLAGS from trying to get Gem to
>> compile... onward :)
>>
>> On Thu, Nov 12, 2009 at 1:23 AM, Rich E  wrote:
>>
>>> On running a regular ./configure in the gui rewrite branch, I get the
>>> error:
>>>
>>> checking for C compiler default output file name...
>>> configure: error: in
>>> `/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43':
>>> configure: error: C compiler cannot create executables
>>> See `config.log' for more details.
>>>
>>> I attached the config.log, any ideas?
>>>
>>> Rich
>>>
>>>
>>> On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner 
>>> wrote:
>>>
>>>>
>>>> The build system in vanilla/extended is pretty ugly, especially for Mac
>>>> OS X.  The build system in the pd-gui-rewrite/0.43 branch has been 
>>>> rewritten
>>>> from scratch to be a full autotools build system.  That should fix the
>>>> -isysroot and --disable-portaudio problem you mention.  Try it out, and we
>>>> can fix any issues there.
>>>>
>>>> svn co
>>>> https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewrite/0.43/
>>>> cd 0.43
>>>> ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
>>>>
>>>> .hc
>>>>
>>>> On Nov 11, 2009, at 6:08 PM, Rich E wrote:
>>>>
>>>> Oops, I accidentally just sent my last post to Hans.  Please read this
>>>> and the post below...
>>>>
>>>> I have been slowly figuring out the last problem, where gcc can't find
>>>> my headers in /usr/include.  It is because the configure line:
>>>>
>>>> if test "x$fat" == "xyes";
>>>> then
>>>> MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
>>>> -arch i386 -arch ppc -Wno-error"
>>>>
>>>> First, I don't know why this is necessary, but I'm sure somebody does.
>>>> I also don't know why OS X 10.6 is being detected as fat anything.
>>>>
>>>> I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc
>>>> can't find a good stdarg.h, as the one include within that sdk has a
>>>> #include_next stdarg.h directive.  Then, with this -sysroot flag, gcc
>>>> doesn't search any other directory and none of the 20 other stdarg.h files
>>>> on my computer are found.  I remove this flag and the header files are 
>>>> found
>>>> elsewhere just fine.
>>>>
>>>> I compiled Portaudio from svn as universal binary with 64bit.  But, this
>>>> library doesn't work with Pd's portaudio source files and the new sources
>>>> don

Re: [PD] compiling externals on snow leopard

[Rich E]

Got it compiled and it looks nice.  The portaudio failed, same as
Pd-Vanilla, but I guess you aren't worried about that because you are
working on getting coreaudio support (which would be nice).  Jack works,
everything is sounds nice and stable.

The only thing I noticed is that expr cannot be found.  I have only tried a
few of the example patches so far.

cheers,
Rich

On Thu, Nov 12, 2009 at 1:57 AM, Rich E  wrote:

> Oops, my fault.  I had some residual CFLAGS from trying to get Gem to
> compile... onward :)
>
> On Thu, Nov 12, 2009 at 1:23 AM, Rich E  wrote:
>
>> On running a regular ./configure in the gui rewrite branch, I get the
>> error:
>>
>> checking for C compiler default output file name...
>> configure: error: in
>> `/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43':
>> configure: error: C compiler cannot create executables
>> See `config.log' for more details.
>>
>> I attached the config.log, any ideas?
>>
>> Rich
>>
>>
>> On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner 
>> wrote:
>>
>>>
>>> The build system in vanilla/extended is pretty ugly, especially for Mac
>>> OS X.  The build system in the pd-gui-rewrite/0.43 branch has been rewritten
>>> from scratch to be a full autotools build system.  That should fix the
>>> -isysroot and --disable-portaudio problem you mention.  Try it out, and we
>>> can fix any issues there.
>>>
>>> svn co
>>> https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewrite/0.43/
>>> cd 0.43
>>> ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
>>>
>>> .hc
>>>
>>> On Nov 11, 2009, at 6:08 PM, Rich E wrote:
>>>
>>> Oops, I accidentally just sent my last post to Hans.  Please read this
>>> and the post below...
>>>
>>> I have been slowly figuring out the last problem, where gcc can't find my
>>> headers in /usr/include.  It is because the configure line:
>>>
>>> if test "x$fat" == "xyes";
>>> then
>>> MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
>>> -arch i386 -arch ppc -Wno-error"
>>>
>>> First, I don't know why this is necessary, but I'm sure somebody does.  I
>>> also don't know why OS X 10.6 is being detected as fat anything.
>>>
>>> I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't
>>> find a good stdarg.h, as the one include within that sdk has a #include_next
>>> stdarg.h directive.  Then, with this -sysroot flag, gcc doesn't search any
>>> other directory and none of the 20 other stdarg.h files on my computer are
>>> found.  I remove this flag and the header files are found elsewhere just
>>> fine.
>>>
>>> I compiled Portaudio from svn as universal binary with 64bit.  But, this
>>> library doesn't work with Pd's portaudio source files and the new sources
>>> don't work with Pd's sources.  So, I can't get past building the portaudio
>>> objects.  I tried just using jack with "./configure --enable-jack
>>> --disable-portaudio", but the build script still tries to build portaudio
>>> and fails.
>>>
>>> This is all with pd vanilla from Miller's website.  I'm also trying to
>>> build the Pd extended sources, but I suppose I should start a new thread for
>>> the problem I hit there..
>>>
>>> On Tue, Nov 10, 2009 at 3:29 AM, Rich E  wrote:
>>>
>>>> Macports made me a universal binary portaudio, thankfully because I
>>>> could not get it to compile as 64 bit from the source (I posted why on the
>>>> portaudio mailing list).
>>>>
>>>> I'm having other annoying problems with my build system, probably
>>>> something very stupid that I am not aware of.  Neither Pd nor Pd-extended
>>>> can find header files in /usr/include.  This isn't so hard to include as a
>>>> CFLAGS flag, but then it still can't find stdarg.h, which just makes me
>>>> think my build system is broken.
>>>>
>>>> I'm working through the various errors to getting Pd-extended building
>>>> on Snow Leopard as 64 bit, but I have to say I'm probably not the best
>>>> candidate as this is the first mac that I've had in years.  Truthfully, I
>>>> was looking forward to a time when things 'just worked' :) 

Re: [PD] compiling externals on snow leopard

[Rich E]

Oops, my fault.  I had some residual CFLAGS from trying to get Gem to
compile... onward :)

On Thu, Nov 12, 2009 at 1:23 AM, Rich E  wrote:

> On running a regular ./configure in the gui rewrite branch, I get the
> error:
>
> checking for C compiler default output file name...
> configure: error: in
> `/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43':
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
>
> I attached the config.log, any ideas?
>
> Rich
>
>
> On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner wrote:
>
>>
>> The build system in vanilla/extended is pretty ugly, especially for Mac OS
>> X.  The build system in the pd-gui-rewrite/0.43 branch has been rewritten
>> from scratch to be a full autotools build system.  That should fix the
>> -isysroot and --disable-portaudio problem you mention.  Try it out, and we
>> can fix any issues there.
>>
>> svn co
>> https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewrite/0.43/
>> cd 0.43
>> ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
>>
>> .hc
>>
>> On Nov 11, 2009, at 6:08 PM, Rich E wrote:
>>
>> Oops, I accidentally just sent my last post to Hans.  Please read this and
>> the post below...
>>
>> I have been slowly figuring out the last problem, where gcc can't find my
>> headers in /usr/include.  It is because the configure line:
>>
>> if test "x$fat" == "xyes";
>> then
>> MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
>> -arch i386 -arch ppc -Wno-error"
>>
>> First, I don't know why this is necessary, but I'm sure somebody does.  I
>> also don't know why OS X 10.6 is being detected as fat anything.
>>
>> I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't
>> find a good stdarg.h, as the one include within that sdk has a #include_next
>> stdarg.h directive.  Then, with this -sysroot flag, gcc doesn't search any
>> other directory and none of the 20 other stdarg.h files on my computer are
>> found.  I remove this flag and the header files are found elsewhere just
>> fine.
>>
>> I compiled Portaudio from svn as universal binary with 64bit.  But, this
>> library doesn't work with Pd's portaudio source files and the new sources
>> don't work with Pd's sources.  So, I can't get past building the portaudio
>> objects.  I tried just using jack with "./configure --enable-jack
>> --disable-portaudio", but the build script still tries to build portaudio
>> and fails.
>>
>> This is all with pd vanilla from Miller's website.  I'm also trying to
>> build the Pd extended sources, but I suppose I should start a new thread for
>> the problem I hit there..
>>
>> On Tue, Nov 10, 2009 at 3:29 AM, Rich E  wrote:
>>
>>> Macports made me a universal binary portaudio, thankfully because I could
>>> not get it to compile as 64 bit from the source (I posted why on the
>>> portaudio mailing list).
>>>
>>> I'm having other annoying problems with my build system, probably
>>> something very stupid that I am not aware of.  Neither Pd nor Pd-extended
>>> can find header files in /usr/include.  This isn't so hard to include as a
>>> CFLAGS flag, but then it still can't find stdarg.h, which just makes me
>>> think my build system is broken.
>>>
>>> I'm working through the various errors to getting Pd-extended building on
>>> Snow Leopard as 64 bit, but I have to say I'm probably not the best
>>> candidate as this is the first mac that I've had in years.  Truthfully, I
>>> was looking forward to a time when things 'just worked' :)  Not there yet.
>>>
>>> Rich
>>>
>>>
>>> On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner 
>>> wrote:
>>>
>>>>
>>>> It seems that portaudio should build as 64-bit, perhaps its worth trying
>>>> to upgrade the portaudio files that are included in Pd-extended.  I 
>>>> recently
>>>> updated the pd-extended/0.42.5 branch to the most recent stable portaudio.
>>>>
>>>>
>>>> http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
>>>>
>>>> .hc
>>>>
>>>> On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
>>>>
>

Re: [PD] compiling externals on snow leopard

[Rich E]

On running a regular ./configure in the gui rewrite branch, I get the error:

checking for C compiler default output file name...
configure: error: in
`/Users/richardeakin/Downloads/src/pd-gui-rewrite-0.43':
configure: error: C compiler cannot create executables
See `config.log' for more details.

I attached the config.log, any ideas?

Rich

On Thu, Nov 12, 2009 at 12:29 AM, Hans-Christoph Steiner wrote:

>
> The build system in vanilla/extended is pretty ugly, especially for Mac OS
> X.  The build system in the pd-gui-rewrite/0.43 branch has been rewritten
> from scratch to be a full autotools build system.  That should fix the
> -isysroot and --disable-portaudio problem you mention.  Try it out, and we
> can fix any issues there.
>
> svn co
> https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewrite/0.43/
> cd 0.43
> ./autogen.sh && ./configure --enable-jack --disable-portaudio && make
>
> .hc
>
> On Nov 11, 2009, at 6:08 PM, Rich E wrote:
>
> Oops, I accidentally just sent my last post to Hans.  Please read this and
> the post below...
>
> I have been slowly figuring out the last problem, where gcc can't find my
> headers in /usr/include.  It is because the configure line:
>
> if test "x$fat" == "xyes";
> then
> MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
> -arch i386 -arch ppc -Wno-error"
>
> First, I don't know why this is necessary, but I'm sure somebody does.  I
> also don't know why OS X 10.6 is being detected as fat anything.
>
> I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't
> find a good stdarg.h, as the one include within that sdk has a #include_next
> stdarg.h directive.  Then, with this -sysroot flag, gcc doesn't search any
> other directory and none of the 20 other stdarg.h files on my computer are
> found.  I remove this flag and the header files are found elsewhere just
> fine.
>
> I compiled Portaudio from svn as universal binary with 64bit.  But, this
> library doesn't work with Pd's portaudio source files and the new sources
> don't work with Pd's sources.  So, I can't get past building the portaudio
> objects.  I tried just using jack with "./configure --enable-jack
> --disable-portaudio", but the build script still tries to build portaudio
> and fails.
>
> This is all with pd vanilla from Miller's website.  I'm also trying to
> build the Pd extended sources, but I suppose I should start a new thread for
> the problem I hit there..
>
> On Tue, Nov 10, 2009 at 3:29 AM, Rich E  wrote:
>
>> Macports made me a universal binary portaudio, thankfully because I could
>> not get it to compile as 64 bit from the source (I posted why on the
>> portaudio mailing list).
>>
>> I'm having other annoying problems with my build system, probably
>> something very stupid that I am not aware of.  Neither Pd nor Pd-extended
>> can find header files in /usr/include.  This isn't so hard to include as a
>> CFLAGS flag, but then it still can't find stdarg.h, which just makes me
>> think my build system is broken.
>>
>> I'm working through the various errors to getting Pd-extended building on
>> Snow Leopard as 64 bit, but I have to say I'm probably not the best
>> candidate as this is the first mac that I've had in years.  Truthfully, I
>> was looking forward to a time when things 'just worked' :)  Not there yet.
>>
>> Rich
>>
>>
>> On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner wrote:
>>
>>>
>>> It seems that portaudio should build as 64-bit, perhaps its worth trying
>>> to upgrade the portaudio files that are included in Pd-extended.  I recently
>>> updated the pd-extended/0.42.5 branch to the most recent stable portaudio.
>>>
>>> http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
>>>
>>> .hc
>>>
>>> On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
>>>
>>>
>>> I'm working getting an Apple AudioUnit sound API support into pd-core
>>> right now.  This will support the iPhone, but should also work on Mac OS X.
>>>  With this, it should be possible to get working audio on Mac OS X without
>>> portaudio.
>>>
>>> AFAIK, Fink does support 64-bit now, so as long as the libs support it,
>>> then Fink should work.  I'd say it would be worthwhile building Pd-extended
>>> 64-bit without the Fink/Macports dependencies, since most included externals
>>> don't

Re: [PD] [GEM] OS X How to compile against SDK 10.5 in os x 10.6

[Rich E]

I ran into the same problem today, trying to build the Gem included with
Pd-extended.  I tried the above advice, but gcc doesn't seem to be getting
the -isysroot command:

++ -c   -g -O2 -fPIC -freg-struct-return -Os -falign-loops=32
-falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math -mmmx
-fpascal-strings   -I..   GemPixImageLoad.cpp -o
../Objects/GemPixImageLoad.o
GemPixImageLoad.cpp:70: error: ‘GraphicsImportComponent’ was not declared in
this scope
.
.
.



On Tue, Oct 20, 2009 at 8:15 PM, Hans-Christoph Steiner wrote:

>
> Post the errors and build transcirpt.
>
> .hc
>
>
> On Oct 20, 2009, at 1:06 AM, Jaime Oliver wrote:
>
>  hi all,
>>
>> I tried:
>>
>> + run aclocal
>> + run autoconf
>> + run ./configure
>> + edit Make.config
>> + added -isysroot /Developer/SDKs/MacOSX10.5.sdk to GEM_CXXFLAGS and
>> GEM_LDFLAGS
>> + make
>>
>> but still get the same error and no way of compiling gem in os x 10.6,
>>
>> still open to suggestions...
>>
>> thanks for the help so far,
>>
>> best,
>>
>> J
>>
>>
>>
>>
>> On Sun, Oct 18, 2009 at 3:38 PM, Hans-Christoph Steiner 
>> wrote:
>>
>>>
>>> -isysroot /Developer/SDKs/MacOSX10.5.sdk usually goes in both CFLAGS and
>>> LDFLAGS.
>>>
>>> .hc
>>>
>>> On Oct 15, 2009, at 10:35 PM, Jaime Oliver wrote:
>>>
>>>  Hi I tried it in several ways and couldn't get it to work. where do
 you usually put this flag?


 On Thu, Oct 15, 2009 at 6:01 AM, chris clepper 
 wrote:

>
> Try this flag:
>
> -isysroot /Developer/SDKs/MacOSX10.5.sdk
>
>
> On Thu, Oct 15, 2009 at 5:51 AM, Jaime Oliver  >
> wrote:
>
>>
>> Hi, I started a new thread as I believe people will start getting this
>> problem soon. The previous thread was: gem compiling error
>>
>> I am trying to compile GEM from source in a macbook pro using osx 10.6
>> and pd-0.42-5, latest Gem (0.92-1) from cvs and xcode 3.21.
>>
>> Chris Clepper suggested to compile against sdk 10.5. sdk 10.5
>> installed, but can't figure out how to make it the target.
>>
>> some programs have a flag like --with-macos=/.../sdk10.5, but can't
>> find any reference in the ./configure -h
>>
>> other sites suggest to modify the makefile, but no luck yet.
>>
>> I also tried: make --include-dir=/Developer/SDKs/MacOSX10.5.sdk/
>>
>> can anyone suggest how to do this?
>>
>> best,
>>
>> J
>>
>>
>>
>>
>> --
>> Jaime E Oliver LR
>>
>> joliv...@ucsd.edu
>> www.realidadvisual.org/jaimeoliver
>> www-crca.ucsd.edu/
>> www.realidadvisual.org
>>
>> 858 202 1522
>> 9168 Regents Rd. Apt. G
>> La Jolla, CA 92037
>> USA
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
>


 --
 Jaime E Oliver LR

 joliv...@ucsd.edu
 www.realidadvisual.org/jaimeoliver
 www-crca.ucsd.edu/
 www.realidadvisual.org

 858 202 1522
 9168 Regents Rd. Apt. G
 La Jolla, CA 92037
 USA

 ___
 Pd-list@iem.at mailing list
 UNSUBSCRIBE and account-management ->
 http://lists.puredata.info/listinfo/pd-list

>>>
>>>
>>>
>>>
>>> 
>>>
>>> There is no way to peace, peace is the way.   -A.J. Muste
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Jaime E Oliver LR
>>
>> joliv...@ucsd.edu
>> www.realidadvisual.org/jaimeoliver
>> www-crca.ucsd.edu/
>> www.realidadvisual.org
>>
>> 858 202 1522
>> 9168 Regents Rd. Apt. G
>> La Jolla, CA 92037
>> USA
>>
>
>
>
>
> 
>
> All information should be free.  - the hacker ethic
>
>
>
>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling externals on snow leopard

[Rich E]

Oops, I accidentally just sent my last post to Hans.  Please read this and
the post below...

I have been slowly figuring out the last problem, where gcc can't find my
headers in /usr/include.  It is because the configure line:

if test "x$fat" == "xyes";
then
MORECFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-arch i386 -arch ppc -Wno-error"

First, I don't know why this is necessary, but I'm sure somebody does.  I
also don't know why OS X 10.6 is being detected as fat anything.

I can install the MacOSX10.4u.sdk from the Xcode disk, but then gcc can't
find a good stdarg.h, as the one include within that sdk has a #include_next
stdarg.h directive.  Then, with this -sysroot flag, gcc doesn't search any
other directory and none of the 20 other stdarg.h files on my computer are
found.  I remove this flag and the header files are found elsewhere just
fine.

I compiled Portaudio from svn as universal binary with 64bit.  But, this
library doesn't work with Pd's portaudio source files and the new sources
don't work with Pd's sources.  So, I can't get past building the portaudio
objects.  I tried just using jack with "./configure --enable-jack
--disable-portaudio", but the build script still tries to build portaudio
and fails.

This is all with pd vanilla from Miller's website.  I'm also trying to build
the Pd extended sources, but I suppose I should start a new thread for the
problem I hit there..

On Tue, Nov 10, 2009 at 3:29 AM, Rich E  wrote:

> Macports made me a universal binary portaudio, thankfully because I could
> not get it to compile as 64 bit from the source (I posted why on the
> portaudio mailing list).
>
> I'm having other annoying problems with my build system, probably something
> very stupid that I am not aware of.  Neither Pd nor Pd-extended can find
> header files in /usr/include.  This isn't so hard to include as a CFLAGS
> flag, but then it still can't find stdarg.h, which just makes me think my
> build system is broken.
>
> I'm working through the various errors to getting Pd-extended building on
> Snow Leopard as 64 bit, but I have to say I'm probably not the best
> candidate as this is the first mac that I've had in years.  Truthfully, I
> was looking forward to a time when things 'just worked' :)  Not there yet.
>
> Rich
>
>
> On Tue, Nov 10, 2009 at 3:03 AM, Hans-Christoph Steiner wrote:
>
>>
>> It seems that portaudio should build as 64-bit, perhaps its worth trying
>> to upgrade the portaudio files that are included in Pd-extended.  I recently
>> updated the pd-extended/0.42.5 branch to the most recent stable portaudio.
>>
>> http://www.portaudio.com/trac/wiki/TutorialDir/Compile/MacintoshCoreAudio
>>
>> .hc
>>
>> On Nov 9, 2009, at 11:57 AM, Hans-Christoph Steiner wrote:
>>
>>
>> I'm working getting an Apple AudioUnit sound API support into pd-core
>> right now.  This will support the iPhone, but should also work on Mac OS X.
>>  With this, it should be possible to get working audio on Mac OS X without
>> portaudio.
>>
>> AFAIK, Fink does support 64-bit now, so as long as the libs support it,
>> then Fink should work.  I'd say it would be worthwhile building Pd-extended
>> 64-bit without the Fink/Macports dependencies, since most included externals
>> don't need any other libs.
>>
>> .hc
>>
>> On Nov 9, 2009, at 10:49 AM, Rich E wrote:
>>
>> Ah, that did the trick.  Thanks.
>>
>> On Mon, Nov 9, 2009 at 3:54 AM, Hans-Christoph Steiner wrote:
>>
>>>
>>> You need to set the LDFLAGS to -arch i386 also.  Or even better, try
>>> doing a 64-bit Snow Leopard build of Pd-extended.
>>>
>>>
>> I'd love to try that, but I'm still working to get a 64-bit Snow Leopard
>> build of Pd-vanilla.  Portaudio won't let me do it yet.  Macports is limited
>> as far as I can see, so I'm having to compile each piece from source.
>>
>>
>> cheers,
>> Rich
>>
>>
>>> .hc
>>>
>>>
>>> On Nov 8, 2009, at 6:58 PM, Rich E wrote:
>>>
>>>  I've been trying to get my externals to compile in to use with
>>>> Pd-extended... in OS X Snow Leopard. So far it hasn't been easy because
>>>> Pd-extended is i386 and my externals are compiling as x86_64.
>>>>
>>>> All I can find on this is to force the build to i386 with the gcc flag
>>>> '-arch i386', but the linker won't allow it:
>>>>
>>>> ld: warning: in incr.o, file is no