Re: [PD] send message to current pd-window
I was kind of hoping to find a simple and existing solution for globally sending hid inputs to the current Pd-patch / subpatch / window inside of Pd. Since I need this only for speeding up programming I found an external solution "btnx" to reprogram the mouse buttons for sending key commands. That does the trick for me. Thanks anyway Ingo > -Ursprüngliche Nachricht- > Von: Jonathan Wilkes [mailto:jancs...@yahoo.com] > Gesendet: Mittwoch, 28. August 2013 18:09 > An: Ingo > Betreff: Re: AW: [PD] send message to current pd-window > > On 08/28/2013 12:25 AM, Ingo wrote: > > Thanks for the suggestion! > > > > [active] can only tell if the current window has the focus or not. > > > > [active] together with [window_name] can actually send the current > window > > name as soon as it gets activated but that would require placing an > > abstraction in every single patch and subpatch. I have a huge amount of > > abstractions and subpatches so that is kind of out of the question. > > > > Somehow Pd has to keep track of which window is currently opened and > active. > > Isn't there a way to get that window / sub patch name without sending it > > from the actual subpatch itself? > > You could make a gui-plugin to do it. Check the tcl/tk documentation > and the gui-rewrite plugin. I'm sure tcl/tk has a way to bind to such > an event (or a way to create one if it doesn't). > > -Jonathan > > > > > Alternatively - is there a way to send letters or ASCII characters from > > within Pd to Pd? Like CTRL + E for edit mode or anything else that can > be > > done by QWERTY key commands? > > > > Ingo > > > > > >> -Ursprüngliche Nachricht- > >> Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > >> Jonathan Wilkes > >> Gesendet: Dienstag, 27. August 2013 17:44 > >> An: pd-list@iem.at > >> Betreff: Re: [PD] send message to current pd-window > >> > >> On 08/27/2013 07:00 AM, Ingo wrote: > >>> I'trying to use a mouse button to toggle between edit mode on off. > >>> I'm using [hid] to get the mouse button and I can send the message to > a > >>> specified window name. > >>> > >>> But how can I send it to the current window that I am working in? > >>> > >>> What would I have to use instead of "windowname"? > >>> > >>> [s pd-"windowname"] > >> [s pd-filename.pd] > >> > >> or > >> > >> [s pd-subpatchname] > >> > >> To automatically figure out which window has the focus, I think > >> there's a cyclone object that does that. Maybe [active] ? > >> > >>> Thanks, Ingo > >>> > >>> > >>> ___ > >>> 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] problems with presets and midi controller
On 29/08/13 11:28, Ronni Montoya wrote: when I'm playing with my midi controller and i change my preset in my patch and then i continue playing with my midi controller, the pd patch is gonna make a jump in the values of my slider, because my midi controllers has a memory and remember the last value it was playing. exactly how the midi controller works here depends on the controller, and how it is set up I was wondering which is the best way to avoid this problem. is it possible to upload my data (preset) to my midi controller? assuming the controller you are talking about is rotary knobs or sliders, then some of them have sliders with motors which will move the slider to match a value sent to that channel, but without motors obviously the position of the slider IS the memory of the last setting and you can't change that without using your fingers! BUT with some controllers you can set them to not send data until you have moved the slider to match the last value you sent to that channel. Clumsy, but much better than jumping back to the old value as soon as you move the slider. If you are a little careful the pd gui sliders and hardware motor sliders can be set to reflect each other and avoid fighting each other in a feedback loop. With rotary encoders, if they are the type which can rotate endlessly then usually they just work easily, and if your controller has leds around the knob to indicate the channel's current value then these are updated when you send to that channel. Rotary encoders with a fixed start and end point are like the sliders without motors, see above, they are fine when they are the only thing controlling a single channel, or when any new preset sent or channel switching is always to the fully up or down setting. If you are talking about buttons, often the controller has options regarding what the send, if they act as toggles or send set values etc. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] problems with presets and midi controller
Hi, I made a patch that has a group of sliders and allows me to save my presets with ssad. The patch works ok, the problem is that when i use a midi controller. when I'm playing with my midi controller and i change my preset in my patch and then i continue playing with my midi controller, the pd patch is gonna make a jump in the values of my slider, because my midi controllers has a memory and remember the last value it was playing. I was wondering which is the best way to avoid this problem. is it possible to upload my data (preset) to my midi controller? cheers R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] 0.45 OSC via binary netsend
netsend/netreceive are vanilla Pd objects; pdsend/pdreceive are shell programs that interoperate with them. cheers Miller On Wed, Aug 28, 2013 at 06:17:11PM -0400, Jonathan Wilkes wrote: > On 08/28/2013 05:49 PM, Max wrote: > >Am 18.08.2013 um 03:51 schrieb Miller Puckette : > >>binary netsend/netreceive (so you should no longer need an extern for OSC) > >has someone tried this? > > Another question-- what's the difference between netsend/receive and > pdsend/receive? > > -Jonathan > > > > > > >___ > >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] Reading txt file inside folder
hi,[read ../data/colors.txt ( doesnt work here on macosx. I ve tried in the following way and it worked. [ read data/colors.txt ( I was wondering if the way im doing this will allow the patch to work only on macosx? If yes, is there is a way of solving this? 2013/8/28, Lorenzo Sutton : > On 28/08/2013 02:17, Ronni Montoya wrote: >> Hi , i have a folder with my pd patch and another folder that stores >> txt files ( my data). >> >> How can i read my txt files from that folder using relative path? >> I need to be able to change the location of my folder and not having >> the necessity of rewriting the path. >> >> >> >> any idea? > Assuming you're using [textfile], something like this should work > > [read ../path_to_file/file.txt( > | > [textfile] > > Lorenzo. > > ___ > 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] routeOSC crash
So that translates as "#bundle", timetag=0, size of first element = 12 "/" ,f 0 So it's opening a bundle with an element whose path is just "/" and a float equal to zero. It could be that totalMix opens the bundle and only closes it at the end, which would probably make Pd crash since it expects to get the entire bundle before processing it. Martin On 2013-08-28 18:25, Max wrote: now suddenly it seems to crash when starting totalMix instead of quitting it. I've started pd with -stderr and it spills out: udpreceive: 35 98 117 110 100 108 101 0 0 0 0 0 0 0 0 0 0 0 0 12 47 0 0 0 44 102 0 0 0 0 0 0 Am 29.08.2013 um 00:12 schrieb Martin Peach : It sounds like TotalMix is sending something that is not OSC when it shuts down. Can you provide the output of udpreceive when that happens? Maybe put a [print] after [udpreceive]. Martin On 2013-08-28 17:35, Max wrote: when closing the sending TotalMix application Pd crashes because of routeOSC (?) 0.44.0-extended-20130213 os x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 routeOSC.pd_darwin 0x0af8c404 routeOSC_list + 16 1 pd 0x0002a7d1 pd_defaultbang + 65 2 pd 0x0002cedb outlet_bang + 59 3 routeOSC.pd_darwin 0x0af8bf3c routeOSC_doanything + 509 4 pd 0x0002b7f8 pd_typedmess + 824 5 pd 0x0002d21d outlet_anything + 77 6 unpackOSC.pd_darwin 0x09ff800c unpackOSC_list + 1298 7 unpackOSC.pd_darwin 0x09ff7e4f unpackOSC_list + 853 8 pd 0x0002d18d outlet_list + 77 9 udpreceive.pd_darwin0x09ff3ea3 udpreceive_read + 406 ___ 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] routeOSC crash
now suddenly it seems to crash when starting totalMix instead of quitting it. I've started pd with -stderr and it spills out: udpreceive: 35 98 117 110 100 108 101 0 0 0 0 0 0 0 0 0 0 0 0 12 47 0 0 0 44 102 0 0 0 0 0 0 Am 29.08.2013 um 00:12 schrieb Martin Peach : > It sounds like TotalMix is sending something that is not OSC when it shuts > down. > Can you provide the output of udpreceive when that happens? Maybe put a > [print] after [udpreceive]. > > Martin > > On 2013-08-28 17:35, Max wrote: >> when closing the sending TotalMix application Pd crashes because of routeOSC >> (?) >> 0.44.0-extended-20130213 os x >> >> >> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >> 0 routeOSC.pd_darwin 0x0af8c404 routeOSC_list + 16 >> 1 pd 0x0002a7d1 pd_defaultbang + 65 >> 2 pd 0x0002cedb outlet_bang + 59 >> 3 routeOSC.pd_darwin 0x0af8bf3c routeOSC_doanything + 509 >> 4 pd 0x0002b7f8 pd_typedmess + 824 >> 5 pd 0x0002d21d outlet_anything + 77 >> 6 unpackOSC.pd_darwin 0x09ff800c unpackOSC_list + 1298 >> 7 unpackOSC.pd_darwin 0x09ff7e4f unpackOSC_list + 853 >> 8 pd 0x0002d18d outlet_list + 77 >> 9 udpreceive.pd_darwin 0x09ff3ea3 udpreceive_read + 406 >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC crash
It sounds like TotalMix is sending something that is not OSC when it shuts down. Can you provide the output of udpreceive when that happens? Maybe put a [print] after [udpreceive]. Martin On 2013-08-28 17:35, Max wrote: when closing the sending TotalMix application Pd crashes because of routeOSC (?) 0.44.0-extended-20130213 os x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 routeOSC.pd_darwin 0x0af8c404 routeOSC_list + 16 1 pd 0x0002a7d1 pd_defaultbang + 65 2 pd 0x0002cedb outlet_bang + 59 3 routeOSC.pd_darwin 0x0af8bf3c routeOSC_doanything + 509 4 pd 0x0002b7f8 pd_typedmess + 824 5 pd 0x0002d21d outlet_anything + 77 6 unpackOSC.pd_darwin 0x09ff800c unpackOSC_list + 1298 7 unpackOSC.pd_darwin 0x09ff7e4f unpackOSC_list + 853 8 pd 0x0002d18d outlet_list + 77 9 udpreceive.pd_darwin0x09ff3ea3 udpreceive_read + 406 ___ 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] 0.45 OSC via binary netsend
On 08/28/2013 05:49 PM, Max wrote: Am 18.08.2013 um 03:51 schrieb Miller Puckette : binary netsend/netreceive (so you should no longer need an extern for OSC) has someone tried this? Another question-- what's the difference between netsend/receive and pdsend/receive? -Jonathan ___ 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] 0.45 OSC via binary netsend
Am 18.08.2013 um 03:51 schrieb Miller Puckette : > binary netsend/netreceive (so you should no longer need an extern for OSC) has someone tried this? signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] routeOSC crash
when closing the sending TotalMix application Pd crashes because of routeOSC (?) 0.44.0-extended-20130213 os x Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 routeOSC.pd_darwin 0x0af8c404 routeOSC_list + 16 1 pd 0x0002a7d1 pd_defaultbang + 65 2 pd 0x0002cedb outlet_bang + 59 3 routeOSC.pd_darwin 0x0af8bf3c routeOSC_doanything + 509 4 pd 0x0002b7f8 pd_typedmess + 824 5 pd 0x0002d21d outlet_anything + 77 6 unpackOSC.pd_darwin 0x09ff800c unpackOSC_list + 1298 7 unpackOSC.pd_darwin 0x09ff7e4f unpackOSC_list + 853 8 pd 0x0002d18d outlet_list + 77 9 udpreceive.pd_darwin0x09ff3ea3 udpreceive_read + 406 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] RME TotalMix controlled with OSC
On 2013-08-28 16:44, Claude Heiland-Allen wrote: Looking at the source, there seems to be a way to set explicit type tags. I haven't checked the help patch, maybe it is documented there. On 28/08/13 21:26, Dan Wilcox wrote: I was thinking that [packOSC] might be interpreting a non-decimal float as an int, but I don't think so ... There is no other way it could be happening - because messages are arrays of atoms and there are no int atoms: Yes, that's why. The default behaviour of [packOSC] checks if an incoming float is the same as its integer representation, if it is, send it as an integer. If Pd used the int atom it wouldn't need to do that. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] RME TotalMix controlled with OSC
oh, yes! that works.
Am 28.08.2013 um 22:42 schrieb Martin Peach :
> You can send ambiguous floats like this:
>
> [sendtyped /to/totalmix f 1{
> |
> [packOSC]
>
> Martin
>
>
> On 2013-08-28 14:33, Max wrote:
>> Hi List, has anyone used OSC o control RME's TotalMix application? The OSC
>> support in there seems rather flawed, for instance the float messages seem
>> to require 1.0 format and 1 will be wrong. How can I sent floats in Pd which
>> have a zero decimal?
>>
>> m.
>>
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] RME TotalMix controlled with OSC
You can send ambiguous floats like this:
[sendtyped /to/totalmix f 1{
|
[packOSC]
Martin
On 2013-08-28 14:33, Max wrote:
Hi List, has anyone used OSC o control RME's TotalMix application? The OSC
support in there seems rather flawed, for instance the float messages seem to
require 1.0 format and 1 will be wrong. How can I sent floats in Pd which have
a zero decimal?
m.
___
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] RME TotalMix controlled with OSC
Looking at the source, there seems to be a way to set explicit type tags. I haven't checked the help patch, maybe it is documented there. On 28/08/13 21:26, Dan Wilcox wrote: > I was thinking that [packOSC] might be interpreting a non-decimal float as an > int, but I don't think so ... There is no other way it could be happening - because messages are arrays of atoms and there are no int atoms: https://sourceforge.net/p/pure-data/svn/17199/tree/trunk/externals/mrpeach/osc/packOSC.c#l578 Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] RME TotalMix controlled with OSC
Yeah all numbers are floats ... but if I do this: [3 < | [int] | [/osc/number $1 < | [packOSC] | [udpsend] packOSC sets the argument type on the receiving end as an int. I've had that bite me in the past for osc apis that are only looking for ints instead of both ints & floats. I was thinking that [packOSC] might be interpreting a non-decimal float as an int, but I don't think so ... On Aug 28, 2013, at 4:10 PM, Max wrote: > hm. since in Pd all numbers are floats printing a 1.0 will show 1 > however I can use [makefilename %s.0] which seems to be a possible workaround. > > > > > > Am 28.08.2013 um 21:58 schrieb Dan Wilcox : > >> Sounds like they don't want ints and sending non decimal values as floats >> results in an int type tag in the OSC message. Try forcing all values to be >> floats with a [float] object. >> >> On Aug 28, 2013, at 3:34 PM, pd-list-requ...@iem.at wrote: >> >>> From: Max >>> Subject: [PD] RME TotalMix controlled with OSC >>> Date: August 28, 2013 2:33:32 PM EDT >>> To: PD list >>> >>> >>> Hi List, has anyone used OSC o control RME's TotalMix application? The OSC >>> support in there seems rather flawed, for instance the float messages seem >>> to require 1.0 format and 1 will be wrong. How can I sent floats in Pd >>> which have a zero decimal? >>> >>> m. >> >> >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >> >> >> >> ___ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > 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] [PD-announce] pd 0.45-1 released
Pd 0.45-1 is up on the usual - http://crca.ucsd.edu/~msp/software.html or: git clone git://git.code.sf.net/p/pure-data/pure-data cd pure-data git checkout -b 0.45 Fixes a small but very annoying bug (backspaces in properties dialogs were erasing the object!) cheers Miller ___ 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] RME TotalMix controlled with OSC
On 28/08/13 21:10, Max wrote: > hm. since in Pd all numbers are floats printing a 1.0 will show 1 > however I can use [makefilename %s.0] which seems to be a possible > workaround. [makefilename %f] But then it might be sent as s string instead of a number (whether float or int). What are you using to send OSC? Claude -- http://mathr.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] RME TotalMix controlled with OSC
hm. since in Pd all numbers are floats printing a 1.0 will show 1 however I can use [makefilename %s.0] which seems to be a possible workaround. forcedecimal.pd Description: Binary data Am 28.08.2013 um 21:58 schrieb Dan Wilcox : > Sounds like they don't want ints and sending non decimal values as floats > results in an int type tag in the OSC message. Try forcing all values to be > floats with a [float] object. > > On Aug 28, 2013, at 3:34 PM, pd-list-requ...@iem.at wrote: > >> From: Max >> Subject: [PD] RME TotalMix controlled with OSC >> Date: August 28, 2013 2:33:32 PM EDT >> To: PD list >> >> >> Hi List, has anyone used OSC o control RME's TotalMix application? The OSC >> support in there seems rather flawed, for instance the float messages seem >> to require 1.0 format and 1 will be wrong. How can I sent floats in Pd which >> have a zero decimal? >> >> m. > > > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > > > > > ___ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] RME TotalMix controlled with OSC
Sounds like they don't want ints and sending non decimal values as floats results in an int type tag in the OSC message. Try forcing all values to be floats with a [float] object. On Aug 28, 2013, at 3:34 PM, pd-list-requ...@iem.at wrote: > From: Max > Subject: [PD] RME TotalMix controlled with OSC > Date: August 28, 2013 2:33:32 PM EDT > To: PD list > > > Hi List, has anyone used OSC o control RME's TotalMix application? The OSC > support in there seems rather flawed, for instance the float messages seem to > require 1.0 format and 1 will be wrong. How can I sent floats in Pd which > have a zero decimal? > > m. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45-0 released
Well, not having a way to get a dual screen Mac I can't test this but here's a guess - it might still be that Pd refuses to allow negative window locations and so throws the abstraction below the visible portion of the smaller of the two screens. I don't know if Tcl/TK has any way of dealing with this I'll have a look but probably can't fix this very quickly. cheers Miller On Wed, Aug 28, 2013 at 07:56:58PM +0200, Max wrote: > Am 23.08.2013 um 21:00 schrieb Miller Puckette : > > As always I'm sure there will be problems here and there - you're welcome > > to report them on the Pd mailing list (pd-list@iem.at) which is always the > > fastest way to get me to see them. > > There is a small bug for users of multiple monitors or resolutions (tested > only on osx, but i guess that's platform independent). > > Some Pd versions ago the patches saved on a bigger resolution screen were > opening off-screen when opened with a smaller resolution or only one monitor. > This has been addressed since. > > In 0.45 if you have the main monitor on the right and a secondary on the left > (thus having negative x values) if you save this patch on the secondary and > open it again it will appear on the primary monitor, even if you have the > second still attached. > > Subpatches and abstractions do show an even stranger behavior: if you have a > patch open on the primary monitor and drag a subpatch on the secondary > monitor (placement relative to the primary monitor doesn't matter here) then > save and close the subpatch, open the subpatch again: you can't. It has > become inaccessible. In a performance situation this is not what you hope > for, because you will only get that window back by re-opening the patch. > > m. > > ___ > 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-announce] pd 0.45-0 released
these bugs were also there on windows and ubuntu, I've always experienced them. They're small things, but it does bother a little, because pd patches are limited to 1 monitor - unless one likes draging windows every time they get open. Am 23.08.2013 um 21:00 schrieb Miller Puckette : As always I'm sure there will be problems here and there - you're welcome to report them on the Pd mailing list (pd-list@iem.at) which is always the fastest way to get me to see them. There is a small bug for users of multiple monitors or resolutions (tested only on osx, but i guess that's platform independent). Some Pd versions ago the patches saved on a bigger resolution screen were opening off-screen when opened with a smaller resolution or only one monitor. This has been addressed since. In 0.45 if you have the main monitor on the right and a secondary on the left (thus having negative x values) if you save this patch on the secondary and open it again it will appear on the primary monitor, even if you have the second still attached. Subpatches and abstractions do show an even stranger behavior: if you have a patch open on the primary monitor and drag a subpatch on the secondary monitor (placement relative to the primary monitor doesn't matter here) then save and close the subpatch, open the subpatch again: you can't. It has become inaccessible. In a performance situation this is not what you hope for, because you will only get that window back by re-opening the patch. m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] RME TotalMix controlled with OSC
Hi List, has anyone used OSC o control RME's TotalMix application? The OSC support in there seems rather flawed, for instance the float messages seem to require 1.0 format and 1 will be wrong. How can I sent floats in Pd which have a zero decimal? m. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45-0 released
Am 23.08.2013 um 21:00 schrieb Miller Puckette : > As always I'm sure there will be problems here and there - you're welcome > to report them on the Pd mailing list (pd-list@iem.at) which is always the > fastest way to get me to see them. There is a small bug for users of multiple monitors or resolutions (tested only on osx, but i guess that's platform independent). Some Pd versions ago the patches saved on a bigger resolution screen were opening off-screen when opened with a smaller resolution or only one monitor. This has been addressed since. In 0.45 if you have the main monitor on the right and a secondary on the left (thus having negative x values) if you save this patch on the secondary and open it again it will appear on the primary monitor, even if you have the second still attached. Subpatches and abstractions do show an even stranger behavior: if you have a patch open on the primary monitor and drag a subpatch on the secondary monitor (placement relative to the primary monitor doesn't matter here) then save and close the subpatch, open the subpatch again: you can't. It has become inaccessible. In a performance situation this is not what you hope for, because you will only get that window back by re-opening the patch. m. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45-0 released
OK, these should be applied and 'pushed' both to branch 0.45 and to 'master'.
cheers
Miller
On Tue, Aug 27, 2013 at 07:21:06PM +0200, IOhannes m zmölnig wrote:
> On 08/23/13 21:00, Miller Puckette wrote:
> > Hi all,
> >
> > Pd version 0.45-0 is available on http://crca.ucsd.edu/~msp/software.htm
>
> cool.
> i started updating the Debian packages...
>
> > As always I'm sure there will be problems here and there - you're welcome
> > to report them on the Pd mailing list (pd-list@iem.at) which is always the
> > fastest way to get me to see them.
>
> two smallish notes.
>
> #1 CFLAGS
> when manually including the Debian-patch "usercflags" (that makes sure
> that user-specified CFLAGS are honoured by prepending the
> configure-detected flags rather than appending), a small oversight has
> occured:
> - on *linux*, the configure-CFLAGS are still appended. instead the
> change was made for *hurd* (aka "GNU"). i think this was simply a
> confusion of "GNU" and "linux".
> - otoh. the *hurd* CFLAGS still include "-O6"
>
> the attached "usercflags.patch" hopefully gets this right. it /also/
> fixes the CFLAGS append/prepend order for cygwin & mingw (though i admit
> that i have not tested this)
>
> #2 BUILD FAILURES with "-Werror=format-security"
> when trying to build with the above error-flag (which pays some extra
> attention to argument passing), the build fails due to two problems.
> a) a call of "error(buf)" withing bug() is rejected, as the
> 'error'-function really reads "error(const char *fmt, ...)" and 'buf' is
> not a format, resp. there are no varargs. the fix is simply to call
> error("consistency check failed: %s", buf)
> and not construct the "consitency-failed" string beforehand. cool, this
> makes the code a little more readable!
> b) more serious, the new [text] object uses 'pd_error("ouch %s", str)',
> when pd_error() really needs a pointer to a pd-object...
> this is a potential crasher bug, as it accesses string memory as objects.
>
> the attached patch "fix_format-security.patch" fixes this as well.
>
>
> gfmasdr
> IOhannes
> Author: Paul Brossier
> Description: do not overwrite user cflags, add them *after* hardcoded ones
> --- puredata.orig/configure.ac
> +++ puredata/configure.ac
> @@ -42,7 +42,7 @@
> if test "x${ANDROID}" = "xno"; then
>LINUX=yes
>portaudio=yes
> - CFLAGS="$CFLAGS -O3 -funroll-loops -fomit-frame-pointer"
> + CFLAGS="-O3 -funroll-loops -fomit-frame-pointer $CFLAGS"
> fi
> EXTERNAL_CFLAGS="-fPIC"
> EXTERNAL_LDFLAGS="-Wl,--export-dynamic -shared -fPIC"
> @@ -50,7 +50,7 @@
> ;;
> *-*-gnu*)
> HURD=yes
> - CFLAGS="-O6 -funroll-loops -fomit-frame-pointer $CFLAGS"
> + CFLAGS="-O3 -funroll-loops -fomit-frame-pointer $CFLAGS"
> EXTERNAL_CFLAGS="-fPIC"
> EXTERNAL_LDFLAGS="-Wl,--export-dynamic -shared -fPIC"
> EXTERNAL_EXTENSION=pd_linux
> @@ -62,7 +62,8 @@
> #to make the final linking phase use g++
> #asio=yes
> portaudio=yes
> - CFLAGS="$CFLAGS -O3 -funroll-loops -fomit-frame-pointer -DWINVER=0x0501
> -D_WIN32_WINNT=0x0501"
> + CFLAGS="-O3 -funroll-loops -fomit-frame-pointer -DWINVER=0x0501
> +-D_WIN32_WINNT=0x0501 $CFLAGS"
> # ASIO is a C++ library, so if its included, then use g++ to build
> CC=g++
> EXTERNAL_CFLAGS="-mms-bitfields"
> @@ -73,7 +74,7 @@
> WINDOWS=yes
> CYGWIN=yes
> portaudio=yes
> - CFLAGS="$CFLAGS -O3 -funroll-loops -fomit-frame-pointer"
> + CFLAGS="-O3 -funroll-loops -fomit-frame-pointer $CFLAGS"
> EXTERNAL_CFLAGS=
> EXTERNAL_LDFLAGS="-Wl,--export-dynamic -shared -lpd"
> EXTERNAL_EXTENSION=dll
> Author: IOhannes m zm??lnig
> Description: printf-like varargs functions must have a proper format;
> use "error('%s', str);" rather than "error(str);"
> also pd_error() requires an instance-pointer as the first argument
> --- puredata.orig/src/s_print.c
> +++ puredata/src/s_print.c
> @@ -282,12 +282,11 @@
> va_list ap;
> t_int arg[8];
> int i;
> -strcpy(buf, "consistency check failed: ");
> va_start(ap, fmt);
> -vsnprintf(buf+strlen(buf), MAXPDSTRING-1, fmt, ap);
> +vsnprintf(buf, MAXPDSTRING-1, fmt, ap);
> va_end(ap);
>
> -error(buf);
> +error("consistency check failed: %s", buf);
> }
>
> /* this isn't worked out yet. */
> --- puredata.orig/src/x_text.c
> +++ puredata/src/x_text.c
> @@ -1174,7 +1174,7 @@
> }
> else
> {
> -pd_error("text sequence: unknown flag '%s'...",
> +pd_error(x, "text sequence: unknown flag '%s'...",
> argv->a_w.w_symbol->s_name);
> }
> argc--; argv++;
> ___
> 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
Re: [PD] [PD-announce] pd 0.45-0 released
OK I think I have a 'fix' but I'm not sure about it (for some reason Pd
was throwing key events to the "last canvas on which a text editor had opened"
but now I can't see why one would do that, and anyway the 'feature' was broken
since 0.43 and I never saw anything wrong... s oI think it's safe just to take
that 'feature' out. I think I can just release the fix as 0.45-1 but am going
to wait until I'm wider awake. Here's a patch if anyone wants to try it:
---
>From fff0b83e6fb500672a4706487358d612db7fe543 Mon Sep 17 00:00:00 2001
From: Miller Puckette
Date: Tue, 27 Aug 2013 22:01:22 -0700
Subject: [PATCH] Took out the canvas_editing business to try to fix the
backspace-in-dialog- getting-sent-to-canvas bug
---
src/g_canvas.c | 3 ---
src/g_canvas.h | 1 -
src/g_editor.c | 4 ++--
src/g_rtext.c | 1 -
4 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/g_canvas.c b/src/g_canvas.c
index 3d38f1c..54079e3 100644
--- a/src/g_canvas.c
+++ b/src/g_canvas.c
@@ -42,7 +42,6 @@ desktops because the borders have both window title area and
menus. */
extern t_pd *newest;
t_class *canvas_class;
int canvas_dspstate;/* whether DSP is on or off */
-t_canvas *canvas_editing; /* last canvas to start text edting */
t_canvas *canvas_whichfind; /* last canvas we did a find in */
t_canvas *canvas_list; /* list of all root canvases */
@@ -725,8 +724,6 @@ void canvas_free(t_canvas *x)
t_gobj *y;
int dspstate = canvas_suspend_dsp();
canvas_noundo(x);
-if (canvas_editing == x)
-canvas_editing = 0;
if (canvas_whichfind == x)
canvas_whichfind = 0;
glist_noselect(x);
diff --git a/src/g_canvas.h b/src/g_canvas.h
index ba6d979..3871444 100644
--- a/src/g_canvas.h
+++ b/src/g_canvas.h
@@ -336,7 +336,6 @@ struct _parentwidgetbehavior
#define CURSOR_EDITMODE_RESIZE 7
EXTERN void canvas_setcursor(t_glist *x, unsigned int cursornum);
-extern t_canvas *canvas_editing;/* last canvas to start text edting */
extern t_canvas *canvas_whichfind; /* last canvas we did a find in */
extern t_canvas *canvas_list; /* list of all root canvases */
extern t_class *vinlet_class, *voutlet_class;
diff --git a/src/g_editor.c b/src/g_editor.c
index 85628b9..90bb78a 100644
--- a/src/g_editor.c
+++ b/src/g_editor.c
@@ -2675,8 +2675,8 @@ static void canvas_texteditor(t_canvas *x)
void glob_key(void *dummy, t_symbol *s, int ac, t_atom *av)
{
-/* canvas_editing can be zero; canvas_key checks for that */
-canvas_key(canvas_editing, s, ac, av);
+/* canvas_key checks for zero */
+canvas_key(0, s, ac, av);
}
void canvas_editmode(t_canvas *x, t_floatarg state)
diff --git a/src/g_rtext.c b/src/g_rtext.c
index 02f7400..f7aa451 100644
--- a/src/g_rtext.c
+++ b/src/g_rtext.c
@@ -449,7 +449,6 @@ void rtext_select(t_rtext *x, int state)
t_canvas *canvas = glist_getcanvas(glist);
sys_vgui(".x%lx.c itemconfigure %s -fill %s\n", canvas,
x->x_tag, (state? "blue" : "black"));
-canvas_editing = canvas;
}
void rtext_activate(t_rtext *x, int state)
--
1.7.11.7
cheers
Miller
On Tue, Aug 27, 2013 at 11:55:58PM -0400, J Oliver wrote:
> it happens consistently in os x 10.7.5.
>
> 1) create a number box.
>
> 2a) If it is selected and I try to delete the "5" in "width" it deletes the
> number box.
>
> 2b) If it is not selected, it won't even delete the "5" in "width".
>
> J
>
> On Aug 27, 2013, at 10:53 PM, Miller Puckette wrote:
>
> > Aha - I can make this malfunction... don't know what's causing it yet. It's
> > quite n abupt surprise when it happens :)
> >
> > On Tue, Aug 27, 2013 at 08:37:25PM +0200, Max wrote:
> >> Am 27.08.2013 um 18:57 schrieb IOhannes m zmölnig :
> >>> On 08/27/13 12:30, Max wrote:
> There is one little annoyance:
> if you select a GUI object, right click fro the properties and then go
> to change on of the fields in the dialog, you can't hit backspace,
> because this deletes the object and closes the properties dialog.
> Somehow the backspace takes effect on the canvas instead of the numbers
> of say changing the values of a slider.
> >>>
> >>> not on my pd-0.45.0.
> >>> this is on debian with xfce4, focus-follows-mouse policy.
> >>
> >> Are you sure the object is selected? the error is occurring for me on OS X
> >> 10.8, haven't tried other platforms.
> >> m.
> >>
> >
> >
> >
> >> ___
> >> 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/lis
Re: [PD] send message to current pd-window
On 08/28/13 06:25, Ingo wrote: > Somehow Pd has to keep track of which window is currently opened and active. not really. pd-gui (tcl/tk) handles all those things. if it detects an event on window "foo", it will send a message to Pd with the receiver "foo". so Pd is quit agnostic about which window is currently open, and allows for multiple windows to send events "simulatenously". i've been exploiting this in Peer Data, to allow M users patch on N windows at the same time (usually N<=M). gfmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45-0 released
Am 28.08.2013 um 09:33 schrieb IOhannes m zmölnig : > On 08/27/13 20:37, Max wrote: >> Am 27.08.2013 um 18:57 schrieb IOhannes m zmölnig : >>> On 08/27/13 12:30, Max wrote: There is one little annoyance: if you select a GUI object, right click fro the properties and then go to change on of the fields in the dialog, you can't hit backspace, because this deletes the object and closes the properties dialog. Somehow the backspace takes effect on the canvas instead of the numbers of say changing the values of a slider. >>> >>> not on my pd-0.45.0. >>> this is on debian with xfce4, focus-follows-mouse policy. >> >> Are you sure the object is selected? the error is occurring for me on OS X >> 10.8, haven't tried other platforms. > > since you mentioned "slider" in the original bugreport, i did my initial > test with [hsl], and i *am* sure that the slider is selected when > deleting the, say, width-value of the slider in the properties dialog. > no problems here. > > i now did another test with the traditional numberbox and there i *can* > reproduce the problem. Interesting. I have the phenomenon with any atom which has a properties window. There is another odd thing: While the properties window opens you can see that "Pd" in the Menu bar changes into "Apple" (?!) Also: the first time you open a properties window after the lauch of Pd it takes significantly longer than subsequent times. (around 5 seconds vs. 0.1 second) m. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Limit bandwith for MIDI output / precise metro
Thank you Miller! Il 20/08/2013 03:00, Miller Puckette ha scritto: Seems like this should be an option... I think it's a bit late to add features to 0.45 but I'll stick it on my list for later. cheers Miller On Thu, Aug 08, 2013 at 11:03:58AM +0200, Nicola Pandini wrote: Hi, I resume this old thread because I compiled pd with Miller's advices to disable MIDI buffering. I tested it with a patch (attached) and this configuration: vkeyb-MidiOUT(ch1) -> pd-MidiIN pd-MidiOUT -> pd-MidiIN so, every time I play a note, I see how much time it takes to pass through pd. I made this test because in my configuration I place pd between my MIDI devices and synth, samplers, etc. The first thing I noticed is that the latency no longer depends on JACK buffer(frames/period), even with the "-jack" startup flag, and the results are: - With the "-jack" flag, the latency was always 1.45ms - With the "-noaudio" flag, the latency was 0ms (sometimes 1.45ms) Just to compare with the standard pd, the best result I achieved is 1.45/2.9ms with "-noaudio". Nicola Il 27/11/2012 18:50, Miller Puckette ha scritto: I believe if you edit s_midi.c and change: if (midi_outqueue[midi_outtail].q_time <= midirealtime) to if (1) and if (midi_inqueue[midi_intail].q_time <= logicaltime) also to if (1) that will make it fast-as-possible. The queueing code should probably be surrounded by an ifdef to make this easier (perhaps someday...) cheers M On Tue, Nov 27, 2012 at 06:23:15PM +0100, Cyrille Henry wrote: Is there a way to bypass all of this? my pd usage usually imply sending and receiving as fast as possible. sending delay usually annoy me. cheers c Le 27/11/2012 18:06, Miller Puckette a écrit : Pd tries to time-stamp MIDI on input and tries to delay sending MIDI output until the correct time; but Pd's accuracy in doing this is limited by the fact that it can't input or output MIID while it is either sleeping or running (only when the scheduler polls for what-to-do-next after either a task or a sleep has finished.) It would be more accurate for Pd to rely on either software interrupts or even better on some underlying OS time-tagging mechanism (for instance by exploiting whatever portmidi does). But I have to admit I've never treated this as a high priority (which one might take as an implied value judgement about MIDI). cheers Miller On Tue, Nov 27, 2012 at 11:44:06AM +0100, Cyrille Henry wrote: Le 27/11/2012 10:36, IOhannes m zmoelnig a écrit : ... with MIDI, Pd doesn't do any buffering and no synchronisation to some external clock is done, so messages appear in bursts which you notice as a inaccurate timing. There is 1 strange thing however : pd did some kind of buffering with midi, in order to synchronise with audio out. if you configure 100ms audio latency, then a midi loop will be between 100 and 105ms. with 10ms audio buffer out, the midi loop is between 10 and 15ms. but this buffer should not change anything on timing except adding latency. cheers c ___ 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 #N canvas 96 143 300 152 10; #X obj 79 68 timer; #X obj 79 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 79 88 nbx 10 30 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 20 -262144 -1 -1 1.45125 256; #X obj 106 48 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 1 90 noteout 3; #X obj 106 3 notein 3; #X obj 1 2 notein 1; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 3 0 0 1; #X connect 5 0 3 0; #X connect 6 0 1 0; #X connect 6 0 4 0; #X connect 6 1 4 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Nicola ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45-0 released
Le 27/08/2013 19:15, Jack a écrit : > Le 27/08/2013 12:30, Max a écrit : > > There is one little annoyance: > > if you select a GUI object, right click fro the properties and then > go to change on of the fields in the dialog, you can't hit backspace, > because this deletes the object and closes the properties dialog. > Somehow the backspace takes effect on the canvas instead of the > numbers of say changing the values of a slider. > > > but generally: amazing, thank you miller. > > :) > > > m. > > > Am 23.08.2013 um 21:00 schrieb Miller Puckette : > > >> Hi all, > >> > >> Pd version 0.45-0 is available on > http://crca.ucsd.edu/~msp/software.htm > >> or via git from sourceforge: > >> git clone git://git.code.sf.net/p/pure-data/pure-data > >> cd pure-data > >> git checkout -b 0.45 > >> > >> As always I'm sure there will be problems here and there - you're > welcome > >> to report them on the Pd mailing list (pd-list@iem.at) which is > always the > >> fastest way to get me to see them. > >> > >> cheers > >> Miller > >> > >> ___ > >> 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 > > > > > ___ > > Pd-list@iem.at mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > Hello, > > I had the same problem with one of my patch today : 'properties' on > canvas then backspace on a field deleted the canvas. > But I can't reproduce it. > ++ > > Jack > > I forgot : the problem occurs on : Ubuntu 13.04 Pd 0.45.0test 2 ++ Jack ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Reading txt file inside folder
On 28/08/2013 02:17, Ronni Montoya wrote: Hi , i have a folder with my pd patch and another folder that stores txt files ( my data). How can i read my txt files from that folder using relative path? I need to be able to change the location of my folder and not having the necessity of rewriting the path. any idea? Assuming you're using [textfile], something like this should work [read ../path_to_file/file.txt( | [textfile] Lorenzo. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45-0 released
On 08/28/13 00:47, Jonathan Wilkes wrote: > +#X obj 407 2 pddp/pddplink http://puredata.info/dev/pddp -text pddp ähm, has pddp made it into Pd-vanilla already? it might be a good idea to submit multiple patches, each implementing a given functionality/feature, so they can be reviewed committed separately. in case of troubles this also makes it easier to track down the culprit. gfmsdar IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Upcoming pd-l2ork release teaser
On 08/27/13 22:34, Jonathan Wilkes wrote: > > Conclusion: teach Fanout(1) and Trigger(2) for situations where ordering > doesn't matter, and Trigger(1) for > situations where it does. The end. only that many Fanout(2) problems originate in a Fanout(1) design, where at some point the patch was extended and branches where execution order did not matter suddenly are merged again in a way where execution order *does* matter. i think that most patchers have heard about [trigger] and it's merits, it just doesn't occur to them that in their specific patch execution order does matter. i dare say that most of the buggy patches posted here (and elsewhere) are buggy exactly because a Fanout(1) mutated into a Fanout(2). as for simon's asynchronous semantics of fan-out, it's probably better to start using it only *after* it has been implemented. conclusion: always make execution order explicit, even if you currently don't care about it. the end. fgmadrs IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Upcoming pd-l2ork release teaser
On 08/27/2013 04:09 PM, Jonathan Wilkes wrote: On 08/27/2013 12:20 PM, Ivica Ico Bukvic wrote: We are coming up on a new pd-l2ork release--one that I am particularly excited about. As I continue to put on the finishing touches, I wanted to share a small but hopefully sweet teaser screenshot with everyone :-) Very cool. Is this using tkpath? Yep :-) It's been quite an overhaul, however, far from a simple drop-in replacement to get this but I think it's been totally worth it. Best wishes, Ico -Jonathan Cheers! ___ 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 -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.45-0 released
On 08/27/13 20:37, Max wrote: > Am 27.08.2013 um 18:57 schrieb IOhannes m zmölnig : >> On 08/27/13 12:30, Max wrote: >>> There is one little annoyance: >>> if you select a GUI object, right click fro the properties and then go to >>> change on of the fields in the dialog, you can't hit backspace, because >>> this deletes the object and closes the properties dialog. Somehow the >>> backspace takes effect on the canvas instead of the numbers of say changing >>> the values of a slider. >> >> not on my pd-0.45.0. >> this is on debian with xfce4, focus-follows-mouse policy. > > Are you sure the object is selected? the error is occurring for me on OS X > 10.8, haven't tried other platforms. since you mentioned "slider" in the original bugreport, i did my initial test with [hsl], and i *am* sure that the slider is selected when deleting the, say, width-value of the slider in the properties dialog. no problems here. i now did another test with the traditional numberbox and there i *can* reproduce the problem. fmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
