Re: [PD] windows pb with pixvideoDS
t'es in t'es bat wrote: Hello i search without success to open a camera on GEM on my PC specifictions of the machine:windows xp home edition 4g of memory Processor amd dual core 5000 x86 family display 2 matrox gs 450 quad pd extended 0.40.3 2008-07-21///Gem 0.91 cvs Now i find something for your reflexion: if i change the rectangle 4 3 object and i put a cube or a sphere it work fine It's very strange... yes it's weird, and it might be related to (installing or not) the matrox openGL drivers. anyhow, if [square] works, then you can use [scale 4 3 1]-[square] instead of [rectangle 4 3] fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Object to handle OpenGL macros
Claude Heiland-Allen wrote: Hans-Christoph Steiner wrote: Looks useful. I wonder how hard it would be to make the GEMgl objects just direclty understand those macros. That might make it easier still http://pd-gem.svn.sourceforge.net/viewvc/pd-gem?view=revrevision=2582 embedd GLconst-const interpreter, so now we can use directly use [GEMglEnable GL_FOG] instead of quirks with [GLdefine]; this is done explicitely; there really should be a way to do it implicetly for all GLenum types i couldn't have said it any better :-) apart from not the ability to implicitely use macros in (some(?)) constructors, i think all the example patches in 09.openGL/ show how to use [GLdefine]. like for all gl-wrapper objects, there is no help-patch :-( gmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] resize pix_buffer dynamically
marius schebella wrote: hi, it seems to be possible to use the message resize x (x=number of frames) to change the size of pix_buffer dynamically, which is actually a good thing, but not documented. agreed. if you feel like making an updated help-patch just do so and send it to me, the list of the pd-gem patch-tracker. fgam,sdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-list Digest, Vol 46, Issue 108
I agree with pasting to the same window the cursor position would be the best solution. But please leave it the way it is for different windows. I always copy objects that have been changed to almost identical windows and they are right in the spot where they belong. Changing this behaviour would be very annoying if you're doing things like this. Ingo well, the current behavior is helpful when pasting into a different window if it has similar dimensions, but if we are copying a piece of a patch which was way down in a window into a new window, then the pasted code ends up in the same place too and one has to go look for it. This also happens because the window doesn't focus in the pasted section, but keeps the 0,0 coordinates. I think in general, (or when pasting to the same window) it would be nice to paste into the last clicked coordinate. In any case I am so used to it by now that I can survive in these conditions. J On Fri, Jan 30, 2009 at 4:03 PM, Miller Puckette mpuck...@imusic1.ucsd.eduwrote: I think if pasting to the same window this would be reasonable - but I've always had in mind, instead, to paste the objects to a new place determined by current cursor position, which would be far better. Just haven't been able to think it through and do it. M On Fri, Jan 30, 2009 at 06:53:22PM -0500, Hans-Christoph Steiner wrote: Hey all, I was thinking that it would be nice if copy-paste had the same response and duplicate, i.e. shifting the position over by 10 pixels in x and y, then pasting. I can't see a good reason why paste doesn't do that. Anyone know of any? Newbies get very frustrated by the current behavior. Regular users get used to the Duplicate command, but I don't know of any other programs where you can't just copy-paste and you need a special function. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] copy-paste vs. duplicate behavior (was Re: Pd-list Digest, Vol 46, Issue 108)
Ingo Scherzinger wrote: I agree with pasting to the same window the cursor position would be the best solution. But please leave it the way it is for different windows. I always copy objects that have been changed to almost identical windows and they are right in the spot where they belong. Changing this behaviour would be very annoying if you're doing things like this. i think that even when copying to different windows, sticking to the mouse-cursor has its merits. e.g. quite often students are having problems, because they have copied a patch twice (or more) to the same (other) window. since there is no visual clue that there are multiple (identical) objects overlapping, patches start to behave weird... this problem could of course also be solved by adding visual clues when objects are overlapping... nevertheless: another idea (which i think has been mentioned here in previous threads) is to: keep the behaviour as it is now, but as soon as the mouse is moved, stick the copied objects to the mouse pointer (i'd suggest to align the upper-left corner of the bounding box of the copied content, rather than sticking with coordinates relative to the original origin). anything else (mouseclick, space-key,...) will place the obects where they currently are. i haven't thought about hidden implications though. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] array size, is this a bug?
hello, i need to use big arrays to store a lot of values, when i change the size of the array from 100 (default ) to 900 and also the x range from 0 to 99 to 0 to 899 and i save my patch when i reopen it the size of the table comes back to 100 and the x range to 0 to 99, why is this? is this a bug? or am i missing something? i dont want to change the size everytime i reopen the patch, any idea? im using pd 0.40.3 - extended thanks in advance pun. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] array size, is this a bug?
punchik punchik wrote: hello, i need to use big arrays to store a lot of values, when i change the size of the array from 100 (default ) to 900 and also the x range from 0 to 99 to 0 to 899 and i save my patch when i reopen it the size of the table comes back to 100 and the x range to 0 to 99, why is this? is this a bug? or am i missing something? i dont want to change the size everytime i reopen the patch, any idea? i guess you are using [table] rather than plain arrays. (or put it otherwise: i cannot reproduce your problem with plain arrays). now, [table] has a 2nd argument, the size of the table which defaults to 100. when you re-open your patch, [table] will initialize again to 100 (if you haven't specified something else). this is very much in-line with the behaviour of most other objects: e.g. if you change the value of [f 100] (by sending a 3 into it), you will get the 100 again when you re-open your patch. solution: either don't use [table] but [pd table] with arrays in it. or manually initialize your table to whatever you want. gfmafgsd IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dynamically altering GUI send/receive symbols
Rory Walsh wrote: Quick question: is it possible to dynamically alter the send/receive symbols for GUI objects? I know that one can change most attributes through various messages but is it possible to alter their send/receive symbols? yes (for the iemguis, that is) just have a look at the [pd edit] in the help patch. (admittedly it is a bit cryptic; have a look at the upper-right corner :-) fgmadr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] copy-paste vs. duplicate behavior
shifting objects when copy/paste in the same window, would be pretty neat. when pasting in an other window it should shift imo. eni Hans-Christoph Steiner wrote: Hey all, I was thinking that it would be nice if copy-paste had the same response and duplicate, i.e. shifting the position over by 10 pixels in x and y, then pasting. I can't see a good reason why paste doesn't do that. Anyone know of any? Newbies get very frustrated by the current behavior. Regular users get used to the Duplicate command, but I don't know of any other programs where you can't just copy-paste and you need a special function. .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ 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 undo ctrl-z
hi all there has been many good ideas about usability features, so here come my most beloved ones: multiple undo be a great improvement. would that be difficult? eni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] de/activate the cursor of selected object box
hi again currently it is possible to use return in object boxes, but afaik this is not needed and stripped to one single line after clicking somewhere outside the box. it'd be neat if the return would activate the cursor in the selected box and the other way around. next step could be selecting the next box by tabulator, but that'd be really fancy. what do you think? eni ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dynamically altering GUI send/receive symbols
On Sunday 01 February 2009 00:55:24 Rory Walsh wrote: Quick question: is it possible to dynamically alter the send/receive symbols for GUI objects? I know that one can change most attributes through various messages but is it possible to alter their send/receive symbols? Rory. p.s. It's been a few years since I posted any messages here. I hope everyone is keeping well! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list --- #N canvas 0 0 450 300 10; #X floatatom 272 142 5 0 0 0 - - -; #X floatatom 90 115 5 0 0 0 - - -; #X obj 273 182 s now; #X msg 86 42 symbol now; #X obj 86 78 dyn-receive test; #X obj 219 76 dyn-send test; #X floatatom 220 47 5 0 0 0 - - -; #X msg 296 51 symbol great; #X obj 92 184 r great; #X floatatom 93 210 5 0 0 0 - - -; #X obj 156 185 r test; #X obj 223 183 s test; #X floatatom 160 216 5 0 0 0 - - -; #X floatatom 222 157 5 0 0 0 - - -; #X connect 0 0 2 0; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 6 0 5 0; #X connect 7 0 5 1; #X connect 8 0 9 0; #X connect 10 0 12 0; #X connect 13 0 11 0; #N canvas 80 349 450 300 10; #N canvas 781 144 450 300 \$0-receive 1; #X obj 10 10 r test; #X obj 10 30 s 1227-dyn-receive; #X connect 0 0 1 0; #X restore 202 43 pd \$0-receive; #X obj 83 130 f \$0; #X obj 56 150 list; #X obj 56 202 s pd-\$0-receive; #X obj 56 110 t a b; #X obj 204 120 outlet; #X obj 56 64 inlet; #X msg 56 170 clear \, obj 10 10 r \$1 \, obj 10 30 s \$2-dyn-receive \, connect 0 0 1 0; #X obj 204 80 r \$0-dyn-receive; #X obj 114 38 loadbang; #X obj 114 77 symbol \$1; #X connect 1 0 2 1; #X connect 2 0 7 0; #X connect 4 0 2 0; #X connect 4 1 1 0; #X connect 6 0 4 0; #X connect 7 0 3 0; #X connect 8 0 5 0; #X connect 9 0 10 0; #X connect 10 0 4 0; #N canvas 566 176 518 325 10; #X obj 34 -8 inlet; #N canvas 781 144 450 300 \$0-receive 1; #X obj 10 10 r test; #X obj 10 30 s 1233-dyn-send; #X connect 0 0 1 0; #X restore 32 44 pd \$0-receive; #X obj 130 149 s pd-\$0-receive; #X obj 158 67 f \$0; #X obj 131 87 list; #X obj 131 47 t a b; #X obj 34 15 s \$0-dyn-send; #X obj 136 14 inlet; #X obj 212 -25 loadbang; #X obj 212 14 symbol \$1; #X msg 127 111 clear \, obj 10 30 r \$2-dyn-send \, obj 10 10 s \$1 \, connect 0 0 1 0; #X connect 0 0 6 0; #X connect 3 0 4 1; #X connect 4 0 10 0; #X connect 5 0 4 0; #X connect 5 1 3 0; #X connect 7 0 5 0; #X connect 8 0 9 0; #X connect 9 0 5 0; #X connect 10 0 2 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dynamically altering GUI send/receive symbols
[send] and [receive] objects have static creation arguments, and cannot be changed dynamically, however its possible to change the attribute using abstractions and a bit of dynamic patching, see the attached files. quite simply a matter of creating the send + receive objects dynamically in a subpatch and routing the send/receive outlet/inlet to the abstractions outlet/inlet.. hope this helps.. dmotd On Sunday 01 February 2009 00:55:24 Rory Walsh wrote: Quick question: is it possible to dynamically alter the send/receive symbols for GUI objects? I know that one can change most attributes through various messages but is it possible to alter their send/receive symbols? Rory. p.s. It's been a few years since I posted any messages here. I hope everyone is keeping well! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 80 349 450 300 10; #N canvas 781 144 450 300 \$0-receive 1; #X obj 10 10 r test; #X obj 10 30 s 1227-dyn-receive; #X connect 0 0 1 0; #X restore 202 43 pd \$0-receive; #X obj 83 130 f \$0; #X obj 56 150 list; #X obj 56 202 s pd-\$0-receive; #X obj 56 110 t a b; #X obj 204 120 outlet; #X obj 56 64 inlet; #X msg 56 170 clear \, obj 10 10 r \$1 \, obj 10 30 s \$2-dyn-receive \, connect 0 0 1 0; #X obj 204 80 r \$0-dyn-receive; #X obj 114 38 loadbang; #X obj 114 77 symbol \$1; #X connect 1 0 2 1; #X connect 2 0 7 0; #X connect 4 0 2 0; #X connect 4 1 1 0; #X connect 6 0 4 0; #X connect 7 0 3 0; #X connect 8 0 5 0; #X connect 9 0 10 0; #X connect 10 0 4 0; #N canvas 566 176 518 325 10; #X obj 34 -8 inlet; #N canvas 781 144 450 300 \$0-receive 1; #X obj 10 10 r test; #X obj 10 30 s 1233-dyn-send; #X connect 0 0 1 0; #X restore 32 44 pd \$0-receive; #X obj 130 149 s pd-\$0-receive; #X obj 158 67 f \$0; #X obj 131 87 list; #X obj 131 47 t a b; #X obj 34 15 s \$0-dyn-send; #X obj 136 14 inlet; #X obj 212 -25 loadbang; #X obj 212 14 symbol \$1; #X msg 127 111 clear \, obj 10 30 r \$2-dyn-send \, obj 10 10 s \$1 \, connect 0 0 1 0; #X connect 0 0 6 0; #X connect 3 0 4 1; #X connect 4 0 10 0; #X connect 5 0 4 0; #X connect 5 1 3 0; #X connect 7 0 5 0; #X connect 8 0 9 0; #X connect 9 0 5 0; #X connect 10 0 2 0; #N canvas 0 0 450 300 10; #X floatatom 272 142 5 0 0 0 - - -; #X floatatom 90 115 5 0 0 0 - - -; #X obj 273 182 s now; #X msg 85 27 symbol now; #X obj 86 78 dyn-receive test; #X obj 219 76 dyn-send test; #X floatatom 220 47 5 0 0 0 - - -; #X msg 289 24 symbol great; #X obj 92 184 r great; #X floatatom 93 210 5 0 0 0 - - -; #X obj 156 185 r test; #X obj 223 183 s test; #X floatatom 160 216 5 0 0 0 - - -; #X floatatom 222 157 5 0 0 0 - - -; #X msg 319 49 symbol test; #X msg 114 52 symbol test; #X connect 0 0 2 0; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 6 0 5 0; #X connect 7 0 5 1; #X connect 8 0 9 0; #X connect 10 0 12 0; #X connect 13 0 11 0; #X connect 14 0 5 1; #X connect 15 0 4 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] dynamically altering GUI send/receive symbols
dmotd wrote: [send] and [receive] objects have static creation arguments, and cannot be [send] does not. fmgasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] multiple undo ctrl-z
I know that the Ableton programmers have joked about the challenges of
designing their endless undo system. I am guessing that it relies upon
keeping track of every change between state saves, since they also have a
nifty feature that will rescue unsaved changes if the system crashes for
some reason. This is stored in a temporary file location specified in the
preferences menu of the program.
So basically the multiple undo system would have to keep a running log in
some temporary file, documenting each state change in the software. Beyond
me, but I agree that this feature is much-desired!
~Kyle
On Sat, Jan 31, 2009 at 10:04 AM, Mathieu Bouchard ma...@artengine.cawrote:
On Sat, 31 Jan 2009, Enrique Erne wrote:
there has been many good ideas about usability features, so here come my
most beloved ones: multiple undo be a great improvement. would that be
difficult?
When I originally harassed Miller so that he implements undo, I thought
he'd go for multiple undo. Instead, he went for single. Basically there's
not much more you have to do to get multiple undo if the single undo was
done right, but that means if the single undo has been implemented with a
future multiple undo in mind. The undo-system is one of the rare parts of
pd source-code that I haven't read, because I wanted to reimplement it from
scratch anyway. So I can't really tell you right away whether Miller's
system could be adapted or not.
My own multiple-undo code doesn't really work well, but that's not because
it's multiple, it's because it's implemented in the client instead, and
there were too many things that had to be changed in the server to get that
working, and I have other excuses as well ;)
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] dynamically altering GUI send/receive symbols
many thanks IOhannes, i have never really realised that [send] without an argument allows for dynamic allocation, many years later this is a minor revelation (which has been looking at me directly in the face for even longer).. unfortunately [receive] does not have the same parameters, so my hack still applies.. cheers.. (old dog new trick) On Sunday 01 February 2009 02:43:28 IOhannes m zmoelnig wrote: [send] does not. fmgasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] copy-paste vs. duplicate behavior (was Re: Pd-list Digest, Vol 46, Issue 108)
Mathieu, I'm sorry to say that you have absolutely no idea what I'm doing. So please don't make unnecessary comments like this one. I'm implementing a LCD user interface that has many, many similar pages but the content and also the number of parameters differs on every single page. No way to do it with abstractions!!! So if anything in all of the pages changes it h a s to be copied back to the same place in the other pages! I totally agree that using abstractions is the more economical way. So actually I do use abstractions where it makes sense of course. However, this doesn't eliminate the need of making similar copies of sub patches and copying objects from one to the other. Ingo On Sat, 31 Jan 2009, Mathieu Bouchard wrote: On Sat, 31 Jan 2009, Ingo Scherzinger wrote: I agree with pasting to the same window the cursor position would be the best solution. But please leave it the way it is for different windows. I always copy objects that have been changed to almost identical windows and they are right in the spot where they belong. Changing this behaviour would be very annoying if you're doing things like this. I believe that in general you shouldn't have to make copy-paste like that, and a language is called powerful when it allows you to avoid the copy-paste and instead replace it with a more concise description of what's going on. In Pd this is made using something called abstractions. But Pd not being so powerful in that sense of the word, there are also many situations where you have to copy-paste, and many situations where it's simpler to copy-paste than to try to contort the thing into something abstractable the pd way. There are also situations that are not really worth abstracting in any language. If you already know all of this, I'm sorry to say it, and in any case, I can only hope that some people will benefit from this email... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] de/activate the cursor of selected object box
Beats having to reach for the mouse too many times a minute, but I'm not sure how we can define next. Probably through a log, in order of creation (timestamp). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] copy-paste vs. duplicate behavior
Yeah, that sounds like a good combo, something like this: - same window, copy - paste, shift by 10x10 pixels, - same window, copy - mouse-click - paste, use mouse coords - copy - different window - paste, use current mouse coordinates and leave The shift 10x10 part is trivial to do, just move the 10x10 shift code from canvas_duplicate to canvas_dopaste. That just leaves me with the question: is there any harm in having it always shift 10x10 until the last option is sorted out? .hc On Jan 30, 2009, at 7:03 PM, Miller Puckette wrote: I think if pasting to the same window this would be reasonable - but I've always had in mind, instead, to paste the objects to a new place determined by current cursor position, which would be far better. Just haven't been able to think it through and do it. M On Fri, Jan 30, 2009 at 06:53:22PM -0500, Hans-Christoph Steiner wrote: Hey all, I was thinking that it would be nice if copy-paste had the same response and duplicate, i.e. shifting the position over by 10 pixels in x and y, then pasting. I can't see a good reason why paste doesn't do that. Anyone know of any? Newbies get very frustrated by the current behavior. Regular users get used to the Duplicate command, but I don't know of any other programs where you can't just copy- paste and you need a special function. .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ 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] seq24 + pd
On Fri, Jan 30, 2009 at 8:16 AM, danomatika danomatika at gmail.com wrote: In regards to the whole Ableton vs/compared to Ardour+pd+etc, I find I like using seq24 to do sequencing outside of pd and pd to make all audio. It is simple and does the job without getting in my way and trying to do too much for me. A few weeks ago I added midi song export to seq4 as a branch on Launchpadhttps://code.launchpad.net/%7Edanomatika/seq24/midi-export. Now I can make a song in seq24 and then load and play it in pd using the mrpeach midifile object. Anyone else using seq24+pd may find this ability useful. Please message the seq24 devs on Launchpad to get them to test and merge my changes to the main branch so it will go into the next version of Ubuntu. (that would be nice) looks like a nice approach, so I tried it today. unfortunately i got the same result as similar things I tried before and which involve midi sent over alsa or jack to/from pd: poor timing (irregular) I uploaded this little test file so you can hear what I mean: http://www.archive.org/download/TestTimingJackSeq24Pd/test_jack_timing_seq24_pd.ogg I connected seq24 to pd by selecting the 'midi bus' for the sequences. I ran pd -jack and qjackctl, but i did not make any midi connections in qjackctl itself, so I'm not sure if jack even has anything to do with it... I did this on ubuntustudio (hardy) do you get better results ? Tim --- Dan Wilcox danomatika.com robotcowboy.com http://www.robotcowboy.com ___ Pd-list at iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz ___ Pd-list at 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-list Digest, Vol 46, Issue 108
Yeah, I thought some people might do that. As it is now, newbies get really annoyed and frustrated, as well as some experienced users. I figure it is easy enough for someone in your position to hit shift- left-arrow, then shift-up-arrow and it'll be back to the original position. That's much easier than recovering from pasting a copy right on top of itself. Maybe someone can come up with an even better idea that solves both issues. .hc On Jan 31, 2009, at 5:34 AM, Ingo Scherzinger wrote: I agree with pasting to the same window the cursor position would be the best solution. But please leave it the way it is for different windows. I always copy objects that have been changed to almost identical windows and they are right in the spot where they belong. Changing this behaviour would be very annoying if you're doing things like this. Ingo well, the current behavior is helpful when pasting into a different window if it has similar dimensions, but if we are copying a piece of a patch which was way down in a window into a new window, then the pasted code ends up in the same place too and one has to go look for it. This also happens because the window doesn't focus in the pasted section, but keeps the 0,0 coordinates. I think in general, (or when pasting to the same window) it would be nice to paste into the last clicked coordinate. In any case I am so used to it by now that I can survive in these conditions. J On Fri, Jan 30, 2009 at 4:03 PM, Miller Puckette mpuck...@imusic1.ucsd.eduwrote: I think if pasting to the same window this would be reasonable - but I've always had in mind, instead, to paste the objects to a new place determined by current cursor position, which would be far better. Just haven't been able to think it through and do it. M On Fri, Jan 30, 2009 at 06:53:22PM -0500, Hans-Christoph Steiner wrote: Hey all, I was thinking that it would be nice if copy-paste had the same response and duplicate, i.e. shifting the position over by 10 pixels in x and y, then pasting. I can't see a good reason why paste doesn't do that. Anyone know of any? Newbies get very frustrated by the current behavior. Regular users get used to the Duplicate command, but I don't know of any other programs where you can't just copy- paste and you need a special function. .hc ___ 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-list Digest, Vol 46, Issue 108
Maybe there could be a menu item that toggles between a) making pasted objects dangle from the mouse (similar to what happens when hitting ctrl-1), or b) shifting 10x10 for the same window and leaving everything as is for different windows. (Hopefully I didn't double post this...) -Jonathan --- On Sat, 1/31/09, Hans-Christoph Steiner h...@eds.org wrote: From: Hans-Christoph Steiner h...@eds.org Subject: Re: [PD] Pd-list Digest, Vol 46, Issue 108 To: Ingo Scherzinger i...@miamiwave.com Cc: pd-list@iem.at Date: Saturday, January 31, 2009, 10:16 PM Yeah, I thought some people might do that. As it is now, newbies get really annoyed and frustrated, as well as some experienced users. I figure it is easy enough for someone in your position to hit shift- left-arrow, then shift-up-arrow and it'll be back to the original position. That's much easier than recovering from pasting a copy right on top of itself. Maybe someone can come up with an even better idea that solves both issues. .hc On Jan 31, 2009, at 5:34 AM, Ingo Scherzinger wrote: I agree with pasting to the same window the cursor position would be the best solution. But please leave it the way it is for different windows. I always copy objects that have been changed to almost identical windows and they are right in the spot where they belong. Changing this behaviour would be very annoying if you're doing things like this. Ingo well, the current behavior is helpful when pasting into a different window if it has similar dimensions, but if we are copying a piece of a patch which was way down in a window into a new window, then the pasted code ends up in the same place too and one has to go look for it. This also happens because the window doesn't focus in the pasted section, but keeps the 0,0 coordinates. I think in general, (or when pasting to the same window) it would be nice to paste into the last clicked coordinate. In any case I am so used to it by now that I can survive in these conditions. J On Fri, Jan 30, 2009 at 4:03 PM, Miller Puckette mpuck...@imusic1.ucsd.eduwrote: I think if pasting to the same window this would be reasonable - but I've always had in mind, instead, to paste the objects to a new place determined by current cursor position, which would be far better. Just haven't been able to think it through and do it. M On Fri, Jan 30, 2009 at 06:53:22PM -0500, Hans-Christoph Steiner wrote: Hey all, I was thinking that it would be nice if copy-paste had the same response and duplicate, i.e. shifting the position over by 10 pixels in x and y, then pasting. I can't see a good reason why paste doesn't do that. Anyone know of any? Newbies get very frustrated by the current behavior. Regular users get used to the Duplicate command, but I don't know of any other programs where you can't just copy- paste and you need a special function. .hc ___ 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] cv.jit is now open source
http://www.iamas.ac.jp/~jovan02/cv/download.html Perhaps this is a bit off topic, but it seems that cv.jit, the opencv library for Max/MSP/Jitter, is now open source. It seems that this code could serve as a good example of how to use aspects of opencv in a dataflow environment, like for pix_opencv or pdp_opencv. .hc I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] copy-paste vs. duplicate behavior (was Re: Pd-list Digest, Vol 46, Issue 108)
Well, what if someone hits paste twice by mistake? Then you still have two copies on top of each other. Both 10x10 pixels moved from the original but still on top of each other. Maybe a more obvious solution would be that two objects on top of each other change color so you know there is something underneath it? I know that's a totally different thing to implement and definitely not as easy as just moving the pasted objects by ten pixels or to the cursor. For the simple solution: I would prefer to use the mouse cursor in the same window and leave the position for other windows. That's because the same window already contains the original objects so the copies need to be moved anyway. Another window probably does not contain identical objects up until now otherwise you wouldn't copy them there. So they should stay in the original position. Ingo Yeah, I was thinking something similar. Perhaps paste should always just leave the whole thing dangling on the mouse pointer until you click to put it down. Or maybe paste just does the 10x10 shift and Duplicate does the dangling behavior. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
