Re: [NEW PORT: audio/rubberband]
ping
On 23 Apr. 2017 8:45 pm, "Tobias Brodel" <brittleh...@gmail.com> wrote:
> necroping,
>
> i've made a few attempts to get the inline assembly built on armv7 with
> clang,
> but it fails in the linking stage, unable to find the `main' function.
>
> so for now i'm just patching that part out, any comments?
>
> please find a tarball attached.
>
> t/
>
> On 01/26/17 18:59, Tobias Brodel wrote:
>
>> On 01/18/17 22:55, Tobias Brodel wrote:
>>
>>> hi stuart, thanks for your response.
>>>
>>> On 01/17/17 23:10, Stuart Henderson wrote:
>>>
>>>> Hi, some quick feedback :
>>>>
>>>> Makefile:
>>>> - "ONLY_FOR_ARCHS = amd64 i386", why?
>>>>
>>>
>>> this was due to a build i tried on armv7 which failed with:
>>>
>>> Error: selected processor does not support `fmrx r3,fpscr'
>>>
>>> i figured this was inline x86 assembly but your question promted
>>> metolook further. turns out its an issue with floating point
>>> instructionson arm.
>>>
>>> i tried copying other ports with `--target=generic' and
>>> `--arch=generic' in CONFIGURE_ARGS with no success. then i tried
>>> CFLAGS+='-mfloat-abi=hard' which the base gcc must not support?
>>> pulling in ports' gcc got me a bit further:
>>>
>>> {standard input}: Assembler messages:
>>> {standard input}:18: Error: selected processor does not support
>>> `fstmfdd sp!,{d8,d9}'
>>> {standard input}:19: Error: unknown pseudo-op: `.vsave'
>>> {standard input}:24: Error: selected processor does not support
>>> `fcpyd d9,d0'
>>> {standard input}:25: Error: selected processor does not support
>>> `fcpyd d8,d1'
>>> {standard input}:37: Error: selected processor does not support
>>> `fcpyd d0,d9'
>>> {standard input}:38: Error: selected processor does not support
>>> `fcpyd d1,d8'
>>> {standard input}:46: Error: selected processor does not support
>>> `fldmfdd ip!,{d8-d9}'
>>>
>>> unsure how to proceed, uncertain what OpenBSD support
>>> for hardware floating point is like on armv7.
>>>
>>>
>> updated tarball attached, simply removed the offending
>> lines of assembly, runs _far_ slower on armv7 but
>> produces expected results. some research suggests that
>> our older binutils in base could be the culprit.
>>
>> perhaps when clang/llvm get enabled on armv7 we can
>> lose this patch.
>>
>> tested on armv7, macppc and amd64
>>
>> - "#GPLv2 only" please add a space, "# GPLv2 only"
>>>> - "COMMENT = Library for ..." lower-case first letter -> "library for"
>>>>
>>>> pkg/DESCR:
>>>> - don't list WWW, it comes automatically from HOMEPAGE in Makefile
>>>>
>>>> pkg/PLIST, Makefile:
>>>> - the linux-style shared library handling needs modifying.
>>>>
>>>
>>> the attached tarball should have fixed these issues.
>>>
>>>
>> are things shaping up?
>>
>> cheers,
>> toby/
>>
>
>
Re: [NEW PORT: audio/rubberband]
necroping,
i've made a few attempts to get the inline assembly built on armv7 with
clang,
but it fails in the linking stage, unable to find the `main' function.
so for now i'm just patching that part out, any comments?
please find a tarball attached.
t/
On 01/26/17 18:59, Tobias Brodel wrote:
On 01/18/17 22:55, Tobias Brodel wrote:
hi stuart, thanks for your response.
On 01/17/17 23:10, Stuart Henderson wrote:
Hi, some quick feedback :
Makefile:
- "ONLY_FOR_ARCHS = amd64 i386", why?
this was due to a build i tried on armv7 which failed with:
Error: selected processor does not support `fmrx r3,fpscr'
i figured this was inline x86 assembly but your question promted
metolook further. turns out its an issue with floating point
instructionson arm.
i tried copying other ports with `--target=generic' and
`--arch=generic' in CONFIGURE_ARGS with no success. then i tried
CFLAGS+='-mfloat-abi=hard' which the base gcc must not support?
pulling in ports' gcc got me a bit further:
{standard input}: Assembler messages:
{standard input}:18: Error: selected processor does not support
`fstmfdd sp!,{d8,d9}'
{standard input}:19: Error: unknown pseudo-op: `.vsave'
{standard input}:24: Error: selected processor does not support
`fcpyd d9,d0'
{standard input}:25: Error: selected processor does not support
`fcpyd d8,d1'
{standard input}:37: Error: selected processor does not support
`fcpyd d0,d9'
{standard input}:38: Error: selected processor does not support
`fcpyd d1,d8'
{standard input}:46: Error: selected processor does not support
`fldmfdd ip!,{d8-d9}'
unsure how to proceed, uncertain what OpenBSD support
for hardware floating point is like on armv7.
updated tarball attached, simply removed the offending
lines of assembly, runs _far_ slower on armv7 but
produces expected results. some research suggests that
our older binutils in base could be the culprit.
perhaps when clang/llvm get enabled on armv7 we can
lose this patch.
tested on armv7, macppc and amd64
- "#GPLv2 only" please add a space, "# GPLv2 only"
- "COMMENT = Library for ..." lower-case first letter -> "library for"
pkg/DESCR:
- don't list WWW, it comes automatically from HOMEPAGE in Makefile
pkg/PLIST, Makefile:
- the linux-style shared library handling needs modifying.
the attached tarball should have fixed these issues.
are things shaping up?
cheers,
toby/
rubberband.tar.gz
Description: application/gzip
Re: possible chromium regression on -current
On 02/23/17 14:26, Bryan Steele wrote: On Wed, Feb 22, 2017 at 11:35:24AM +, Dimitris Papastamos wrote: Hi everyone, I think at some point in the last week a possible chromium regression was introduced. Youtube videos give a playback error. This is what I get in the log: [11087:-105893312:0221/190453.466753:ERROR:sync_control_vsync_provider.cc(144)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0. [70895:441591864:0221/190454.467559:ERROR:network_interfaces_posix.cc(63)] Not implemented reached in bool net::GetNetworkList(NetworkInterfaceList *, int) [97863:574132800:0221/190457.039780:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR pipeline: initialization failed [11087:-105893312:0221/190457.133204:ERROR:sync_control_vsync_provider.cc(144)] glXGetSyncValuesOML should not return TRUE with a media stream counter of 0. [97863:574132800:0221/190457.459204:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR pipeline: initialization failed [70895:441591864:0221/190500.474199:ERROR:network_interfaces_posix.cc(63)] Not implemented reached in bool net::GetNetworkList(NetworkInterfaceList *, int) Any ideas? I noticed this too and mentioned it on a ports dev chat, I remember it working a few weeks ago. But I'm not sure if it stopped working before or after the 56.0.2924.87 update.. It appears to affect only some HTML5 video streaming sites, like Youtube and Twitch, but embedded still works. It doesn't appear to be drm(4) obviously related either as WebGL demos work fine. At least a few people said it still works for them, so perhaps it's a certain hardware combination that's causing this? -Bryan. I'm experiencing this too: Thinkpad T430 on recent snapshots. inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) t/
Re: [NEW PORT: audio/rubberband]
ping
On 2 Feb. 2017 8:46 am, "Tobias Brodel" <brittleh...@gmail.com> wrote:
> ping
>
> On 26 Jan. 2017 7:02 pm, "Tobias Brodel" <brittleh...@gmail.com> wrote:
>
>> whoops, wrong tarball. sorry for the noise!
>>
>> On 01/26/17 18:59, Tobias Brodel wrote:
>>
>>> On 01/18/17 22:55, Tobias Brodel wrote:
>>>
>>>> hi stuart, thanks for your response.
>>>>
>>>> On 01/17/17 23:10, Stuart Henderson wrote:
>>>>
>>>>> Hi, some quick feedback :
>>>>>
>>>>> Makefile:
>>>>> - "ONLY_FOR_ARCHS = amd64 i386", why?
>>>>>
>>>>
>>>> this was due to a build i tried on armv7 which failed with:
>>>>
>>>> Error: selected processor does not support `fmrx r3,fpscr'
>>>>
>>>> i figured this was inline x86 assembly but your question promted
>>>> metolook further. turns out its an issue with floating point
>>>> instructionson arm.
>>>>
>>>> i tried copying other ports with `--target=generic' and
>>>> `--arch=generic' in CONFIGURE_ARGS with no success. then i tried
>>>> CFLAGS+='-mfloat-abi=hard' which the base gcc must not support?
>>>> pulling in ports' gcc got me a bit further:
>>>>
>>>> {standard input}: Assembler messages:
>>>> {standard input}:18: Error: selected processor does not support
>>>> `fstmfdd sp!,{d8,d9}'
>>>> {standard input}:19: Error: unknown pseudo-op: `.vsave'
>>>> {standard input}:24: Error: selected processor does not support
>>>> `fcpyd d9,d0'
>>>> {standard input}:25: Error: selected processor does not support
>>>> `fcpyd d8,d1'
>>>> {standard input}:37: Error: selected processor does not support
>>>> `fcpyd d0,d9'
>>>> {standard input}:38: Error: selected processor does not support
>>>> `fcpyd d1,d8'
>>>> {standard input}:46: Error: selected processor does not support
>>>> `fldmfdd ip!,{d8-d9}'
>>>>
>>>> unsure how to proceed, uncertain what OpenBSD support
>>>> for hardware floating point is like on armv7.
>>>>
>>>>
>>> updated tarball attached, simply removed the offending
>>> lines of assembly, runs _far_ slower on armv7 but
>>> produces expected results. some research suggests that
>>> our older binutils in base could be the culprit.
>>>
>>> perhaps when clang/llvm get enabled on armv7 we can
>>> lose this patch.
>>>
>>> tested on armv7, macppc and amd64
>>>
>>> - "#GPLv2 only" please add a space, "# GPLv2 only"
>>>>> - "COMMENT = Library for ..." lower-case first letter -> "library for"
>>>>>
>>>>> pkg/DESCR:
>>>>> - don't list WWW, it comes automatically from HOMEPAGE in Makefile
>>>>>
>>>>> pkg/PLIST, Makefile:
>>>>> - the linux-style shared library handling needs modifying.
>>>>>
>>>>
>>>> the attached tarball should have fixed these issues.
>>>>
>>>>
>>> are things shaping up?
>>>
>>> cheers,
>>> toby/
>>>
>>
>>
Re: [NEW PORT: audio/rubberband]
ping
On 26 Jan. 2017 7:02 pm, "Tobias Brodel" <brittleh...@gmail.com> wrote:
> whoops, wrong tarball. sorry for the noise!
>
> On 01/26/17 18:59, Tobias Brodel wrote:
>
>> On 01/18/17 22:55, Tobias Brodel wrote:
>>
>>> hi stuart, thanks for your response.
>>>
>>> On 01/17/17 23:10, Stuart Henderson wrote:
>>>
>>>> Hi, some quick feedback :
>>>>
>>>> Makefile:
>>>> - "ONLY_FOR_ARCHS = amd64 i386", why?
>>>>
>>>
>>> this was due to a build i tried on armv7 which failed with:
>>>
>>> Error: selected processor does not support `fmrx r3,fpscr'
>>>
>>> i figured this was inline x86 assembly but your question promted
>>> metolook further. turns out its an issue with floating point
>>> instructionson arm.
>>>
>>> i tried copying other ports with `--target=generic' and
>>> `--arch=generic' in CONFIGURE_ARGS with no success. then i tried
>>> CFLAGS+='-mfloat-abi=hard' which the base gcc must not support?
>>> pulling in ports' gcc got me a bit further:
>>>
>>> {standard input}: Assembler messages:
>>> {standard input}:18: Error: selected processor does not support
>>> `fstmfdd sp!,{d8,d9}'
>>> {standard input}:19: Error: unknown pseudo-op: `.vsave'
>>> {standard input}:24: Error: selected processor does not support
>>> `fcpyd d9,d0'
>>> {standard input}:25: Error: selected processor does not support
>>> `fcpyd d8,d1'
>>> {standard input}:37: Error: selected processor does not support
>>> `fcpyd d0,d9'
>>> {standard input}:38: Error: selected processor does not support
>>> `fcpyd d1,d8'
>>> {standard input}:46: Error: selected processor does not support
>>> `fldmfdd ip!,{d8-d9}'
>>>
>>> unsure how to proceed, uncertain what OpenBSD support
>>> for hardware floating point is like on armv7.
>>>
>>>
>> updated tarball attached, simply removed the offending
>> lines of assembly, runs _far_ slower on armv7 but
>> produces expected results. some research suggests that
>> our older binutils in base could be the culprit.
>>
>> perhaps when clang/llvm get enabled on armv7 we can
>> lose this patch.
>>
>> tested on armv7, macppc and amd64
>>
>> - "#GPLv2 only" please add a space, "# GPLv2 only"
>>>> - "COMMENT = Library for ..." lower-case first letter -> "library for"
>>>>
>>>> pkg/DESCR:
>>>> - don't list WWW, it comes automatically from HOMEPAGE in Makefile
>>>>
>>>> pkg/PLIST, Makefile:
>>>> - the linux-style shared library handling needs modifying.
>>>>
>>>
>>> the attached tarball should have fixed these issues.
>>>
>>>
>> are things shaping up?
>>
>> cheers,
>> toby/
>>
>
>
Re: [NEW PORT: audio/rubberband]
whoops, wrong tarball. sorry for the noise!
On 01/26/17 18:59, Tobias Brodel wrote:
On 01/18/17 22:55, Tobias Brodel wrote:
hi stuart, thanks for your response.
On 01/17/17 23:10, Stuart Henderson wrote:
Hi, some quick feedback :
Makefile:
- "ONLY_FOR_ARCHS = amd64 i386", why?
this was due to a build i tried on armv7 which failed with:
Error: selected processor does not support `fmrx r3,fpscr'
i figured this was inline x86 assembly but your question promted
metolook further. turns out its an issue with floating point
instructionson arm.
i tried copying other ports with `--target=generic' and
`--arch=generic' in CONFIGURE_ARGS with no success. then i tried
CFLAGS+='-mfloat-abi=hard' which the base gcc must not support?
pulling in ports' gcc got me a bit further:
{standard input}: Assembler messages:
{standard input}:18: Error: selected processor does not support
`fstmfdd sp!,{d8,d9}'
{standard input}:19: Error: unknown pseudo-op: `.vsave'
{standard input}:24: Error: selected processor does not support
`fcpyd d9,d0'
{standard input}:25: Error: selected processor does not support
`fcpyd d8,d1'
{standard input}:37: Error: selected processor does not support
`fcpyd d0,d9'
{standard input}:38: Error: selected processor does not support
`fcpyd d1,d8'
{standard input}:46: Error: selected processor does not support
`fldmfdd ip!,{d8-d9}'
unsure how to proceed, uncertain what OpenBSD support
for hardware floating point is like on armv7.
updated tarball attached, simply removed the offending
lines of assembly, runs _far_ slower on armv7 but
produces expected results. some research suggests that
our older binutils in base could be the culprit.
perhaps when clang/llvm get enabled on armv7 we can
lose this patch.
tested on armv7, macppc and amd64
- "#GPLv2 only" please add a space, "# GPLv2 only"
- "COMMENT = Library for ..." lower-case first letter -> "library for"
pkg/DESCR:
- don't list WWW, it comes automatically from HOMEPAGE in Makefile
pkg/PLIST, Makefile:
- the linux-style shared library handling needs modifying.
the attached tarball should have fixed these issues.
are things shaping up?
cheers,
toby/
rubberband.tar.gz
Description: application/gzip
Re: [NEW PORT: audio/rubberband]
On 01/18/17 22:55, Tobias Brodel wrote:
hi stuart, thanks for your response.
On 01/17/17 23:10, Stuart Henderson wrote:
Hi, some quick feedback :
Makefile:
- "ONLY_FOR_ARCHS = amd64 i386", why?
this was due to a build i tried on armv7 which failed with:
Error: selected processor does not support `fmrx r3,fpscr'
i figured this was inline x86 assembly but your question promted
metolook further. turns out its an issue with floating point
instructionson arm.
i tried copying other ports with `--target=generic' and
`--arch=generic' in CONFIGURE_ARGS with no success. then i tried
CFLAGS+='-mfloat-abi=hard' which the base gcc must not support?
pulling in ports' gcc got me a bit further:
{standard input}: Assembler messages:
{standard input}:18: Error: selected processor does not support
`fstmfdd sp!,{d8,d9}'
{standard input}:19: Error: unknown pseudo-op: `.vsave'
{standard input}:24: Error: selected processor does not support
`fcpyd d9,d0'
{standard input}:25: Error: selected processor does not support
`fcpyd d8,d1'
{standard input}:37: Error: selected processor does not support
`fcpyd d0,d9'
{standard input}:38: Error: selected processor does not support
`fcpyd d1,d8'
{standard input}:46: Error: selected processor does not support
`fldmfdd ip!,{d8-d9}'
unsure how to proceed, uncertain what OpenBSD support
for hardware floating point is like on armv7.
updated tarball attached, simply removed the offending
lines of assembly, runs _far_ slower on armv7 but
produces expected results. some research suggests that
our older binutils in base could be the culprit.
perhaps when clang/llvm get enabled on armv7 we can
lose this patch.
tested on armv7, macppc and amd64
- "#GPLv2 only" please add a space, "# GPLv2 only"
- "COMMENT = Library for ..." lower-case first letter -> "library for"
pkg/DESCR:
- don't list WWW, it comes automatically from HOMEPAGE in Makefile
pkg/PLIST, Makefile:
- the linux-style shared library handling needs modifying.
the attached tarball should have fixed these issues.
are things shaping up?
cheers,
toby/
rubberband.tar.gz
Description: application/gzip
Re: [NEW PORT: audio/rubberband]
hi stuart, thanks for your response.
On 01/17/17 23:10, Stuart Henderson wrote:
Hi, some quick feedback :
Makefile:
- "ONLY_FOR_ARCHS = amd64 i386", why?
this was due to a build i tried on armv7 which failed with:
Error: selected processor does not support `fmrx r3,fpscr'
i figured this was inline x86 assembly but your question promted
metolook further. turns out its an issue with floating point
instructionson arm.
i tried copying other ports with `--target=generic' and
`--arch=generic' in CONFIGURE_ARGS with no success. then i tried
CFLAGS+='-mfloat-abi=hard' which the base gcc must not support?
pulling in ports' gcc got me a bit further:
{standard input}: Assembler messages:
{standard input}:18: Error: selected processor does not support
`fstmfdd sp!,{d8,d9}'
{standard input}:19: Error: unknown pseudo-op: `.vsave'
{standard input}:24: Error: selected processor does not support
`fcpyd d9,d0'
{standard input}:25: Error: selected processor does not support
`fcpyd d8,d1'
{standard input}:37: Error: selected processor does not support
`fcpyd d0,d9'
{standard input}:38: Error: selected processor does not support
`fcpyd d1,d8'
{standard input}:46: Error: selected processor does not support
`fldmfdd ip!,{d8-d9}'
unsure how to proceed, uncertain what OpenBSD support
for hardware floating point is like on armv7.
- "#GPLv2 only" please add a space, "# GPLv2 only"
- "COMMENT = Library for ..." lower-case first letter -> "library for"
pkg/DESCR:
- don't list WWW, it comes automatically from HOMEPAGE in Makefile
pkg/PLIST, Makefile:
- the linux-style shared library handling needs modifying.
the attached tarball should have fixed these issues.
Since you are pretty new to ports on OpenBSD, please get the first
one in good shape before sending others, as most of my comments apply
to the others too.
sure thing, sorry for the noise, i now realise it was
poor etiquette.
thanks for having a look at this,
toby/
rubberband.tar.gz
Description: application/gzip
[NEW PORT: audio/lv2]
lilv is a C library for embedding LV2 plugins in audio applications. It depends on recently posted ports audio/lv2, devel/serd, devel/sord and devel/sratom. lilv itself is a dependency for newer versions of audio/ardour. Tested on amd64 and armv7. t/ lilv.tar.gz Description: application/gzip
[NEW PORT: audio/lilv]
lilv is a C library for embedding LV2 plugins in audio applications. It depends on recently posted ports audio/lv2, devel/serd, devel/sord and devel/sratom. lilv itself is a dependency for newer versions of audio/ardour. Tested on amd64 and armv7. t/ lilv.tar.gz Description: application/gzip
[NEW PORT: devel/sratom]
sratom is a C library for serialising LV2 atoms to and from RDF. It depends on recently posted ports audio/lv2, devel/serd and devel/sord. sratom itself is a dependency for newer versions of audio/ardour. Unsure about appropriate CATEGORIES for this one: devel, audio or both? Tested on amd64 and armv7. t/ sratom.tar.gz Description: application/gzip
[NEW PORT: devel/sord]
sord is a C library for storing RDF data in memory. It depends on recently posted port devel/serd and is itself a dependency for newer versions of audio/ardour. Tested on amd64 and armv7. t/ sord.tar.gz Description: application/gzip
[NEW PORT: devel/serd]
serd is a C library for RDF syntax with no runtime dependencies outside of libc and libm. It is a dependency required for new versions of audio/ardour. Tested on amd64 and armv7. t/ serd.tar.gz Description: application/gzip
[NEW PORT: audio/lv2]
Lv2 is an audio plugin standard designed to replace LADSPA. This is another dependency for newer versions of audio/ardour. Tested on amd64 and armv7. Existing ports such as audio/calf can enable this API, though this has not been tested. t/ lv2.tar.gz Description: application/gzip
[NEW PORT: audio/rubberband]
Please find attached a port for rubberband, a library and utility for timestretching and repitching audio. It is one of a few new dependencies required for an update to audio/ardour. I'm pretty new to ports so any feedback would be much appreciated. Tested on amd64. Cheers, toby/ rubberband.tar.gz Description: application/gzip
Re: devel/sdl2 bug since update to 2.0.5
Hi Ryan, >I am curious if the issue can be reproduced by >another user in Gnome other than myself. Just for the sake of it I got quakespasm going (just using `pkg_add') and was unable to reproduce your menu bugs in GNOME. Please note that this was my first time running quakespasm but it seemed to work fine for me (today's snapshot and packages, ThinkPad T430. toby/
Re: New Port: audio/pd
On 10/07/16 07:53, Alexandre Ratchov wrote: On Thu, Oct 06, 2016 at 10:55:26AM +1100, Tobias Brodel wrote: Hi, this is my first attempt at an OpenBSD port, it's for audio/pd. Feedback would be greatly appreciated. COMMENT: Realtime computer music and graphics system. DESCR: Pure Data (Pd) is an open source visual programming language. It is used to process and generate sound, video, 2D/3D graphics. Pd interfaces with sensors, input devices and MIDI and can be operated across local and remote networks. Pd is suitable for learning basic multimedia processing and visual programming techniques, as well as for realising complex systems for large-scale projects. WWW: http://puredata.info Thanks. Audio wont work on top of the OSS api. Audio support of libossaudio never worked well (except for trivial players and on certain devices only) so it was removed after OpenBSD 5.7 release. The least time consuming approach to make audio work reliably on OpenBSD would be to write a sndio audio & midi backend for pd. I would start with a copy of one of the working s_audio_*.c and replace calls to open, read and write with the appropriate sio_xxx() functions. All the sycnronization and overrun/underrun recovery bits could be dropped as this is handled by sndio internally. There's no device enumeration, so you could just hardcode "default". There's no mmap(), so corresponding bits could go away as well. Same about MIDI. Another option would be to enable the portaudio or jack backends. Thanks for your feedback. I did have audio running under OSS but it was very picky about the order in which to connect things, and MIDI support was nonexistent. A sndio backend would be much better, and after having a play with it last night it seems to be *loads* simpler than ALSA/OSS. I have been having a couple of very basic issues though. Please excuse me if I'm overlooking something obvious, but does every sndio client need to implement the `sio_hdl' and `sio_ops' structs privately? Jack and portaudio should be included too, so I'll work on that before sending in another tarball. Thanks for your help, toby/
New Port: audio/pd
Hi, this is my first attempt at an OpenBSD port, it's for audio/pd. Feedback would be greatly appreciated. COMMENT: Realtime computer music and graphics system. DESCR: Pure Data (Pd) is an open source visual programming language. It is used to process and generate sound, video, 2D/3D graphics. Pd interfaces with sensors, input devices and MIDI and can be operated across local and remote networks. Pd is suitable for learning basic multimedia processing and visual programming techniques, as well as for realising complex systems for large-scale projects. WWW: http://puredata.info toby/ pd.tar.gz Description: application/gzip
