I seem to be stepping into all the weird stuff here...
For the past few hours, I can't seem to get any input via adc~, in places where it worked before and in test patches. The input works OK in the GNOME sound recorder (and I've also booted into Windoze and confirmed that it works there), but nothing seems to come in via adc~ objects in PD. Hooking it through snapshot~ into a VU meter and number box (adapting the test patch in 5.reference/snapshot~.pd ) I get no result from input, just the same low-level noise that I see when I'm not sounding.
I may have missed something again...
(The more I work with PD and like it, the more I wish there was a solid manual for it. If I could afford it, I'd immerse myself in the software and write one from the existing sources and what I learn...)
On Mon, Dec 24, 2001 at 10:22:13PM -0600, Joseph Zitt wrote:
I seem to be stepping into all the weird stuff here...
For the past few hours, I can't seem to get any input via adc~, in places where it worked before and in test patches. The input works OK in the GNOME sound recorder (and I've also booted into Windoze and confirmed that it works there), but nothing seems to come in via adc~ objects in PD. Hooking it through snapshot~ into a VU meter and number box (adapting the test patch in 5.reference/snapshot~.pd ) I get no result from input, just the same low-level noise that I see when I'm not sounding.
Self-replying here: I see that the peak level meters in the main window do respond to incoming sound, jumping from the usual background levels of about 30 (unfortunately, I'm developing this in a noisy basement), but jumping to about 90 when I speak into the mic.
BTW, this is in RedHat Linux 7.2 with pd version 0.34
I may have missed something again...
(The more I work with PD and like it, the more I wish there was a solid manual for it. If I could afford it, I'd immerse myself in the software and write one from the existing sources and what I learn...)
-- |> ~The only thing that is not art is inattention~ --- Marcel Duchamp <| | jzitt@metatronpress.com http://www.metatronpress.com/jzitt | | Latest CDs: Collaborations/ All Souls http://www.mp3.com/josephzitt | | Comma: Voices of New Music Silence: the John Cage Discussion List |
Replying to myself again:
While I haven't gotten the broken patches working, I managed to recreate them piece by piece in new patches, doing some copying and pasting and some typing from scratch. (
One thing that I found confused me in copying and pasting is that I expected the pasted objects to appear at the mouse pointer location, rather than at the same ccordinates as in the window from which they were copied. While I could see the reason for this from a programming standpoint, I found it to be a problem, since quite often the paste happened outside the visible window. When that happened, until I caught on to what was happening, I sometimes pasted multiple copies, thinking that the first paste didn't work.)
Another thought: is there a listing anywhere of the characteristics of externals and other objects, showing the inlets, outlets, and global variables used in them? I'm envisioning something like:
inlet 1: signal: audio signal inlet 2: signal: audio signal inlet 3: number: mix amount values: 0: left signal only 100: right signal only outlet 1: signal: blended signal variable: number: foo_master: determines global level of bogosity
It would be good to have this info in something like the Pure Data Base. If no such collection exists, I could work on pulling together something like it over time as I learn PD (maybe in dull moments while I'm on tour over the next two months). ("cause I'm a tech writer, and I like collecting and writing up this kind of stuff :-] )
On Tue, Dec 25, 2001 at 05:06:03PM -0600, Joseph Zitt wrote:
On Mon, Dec 24, 2001 at 10:22:13PM -0600, Joseph Zitt wrote:
I seem to be stepping into all the weird stuff here...
For the past few hours, I can't seem to get any input via adc~, in places where it worked before and in test patches. The input works OK in the GNOME sound recorder (and I've also booted into Windoze and confirmed that it works there), but nothing seems to come in via adc~ objects in PD. Hooking it through snapshot~ into a VU meter and number box (adapting the test patch in 5.reference/snapshot~.pd ) I get no result from input, just the same low-level noise that I see when I'm not sounding.
Self-replying here: I see that the peak level meters in the main window do respond to incoming sound, jumping from the usual background levels of about 30 (unfortunately, I'm developing this in a noisy basement), but jumping to about 90 when I speak into the mic.
BTW, this is in RedHat Linux 7.2 with pd version 0.34
I may have missed something again...
(The more I work with PD and like it, the more I wish there was a solid manual for it. If I could afford it, I'd immerse myself in the software and write one from the existing sources and what I learn...)
This is a good idea... I'll try to find a solution for pasting that behaves better...
cheers Miller
One thing that I found confused me in copying and pasting is that I expected the pasted objects to appear at the mouse pointer location, rather than at the same ccordinates as in the window from which they were copied. While I could see the reason for this from a programming standpoint, I found it to be a problem, since quite often the paste happened outside the visible window. When that happened, until I caught on to what was happening, I sometimes pasted multiple copies, thinking that the first paste didn't work.)
On Thu, Dec 27, 2001 at 05:47:10PM -0800, Miller Puckette wrote:
This is a good idea... I'll try to find a solution for pasting that behaves better...
FWIW, the solution that I find most intuitive as a user (though others may disagree) is that the pasted material appears in the same relation to the cursor position in the window into which it is pasted that it did in the window from which it was cut or copied. That is, for example, if a region whose upper right corner was at x=100 y=200 while the cursor was at x=150 y=250, when pasted into a window where the cursor is at x= 350 y=450 it would appear with its upper right corner at x=300 y=400. Unless I've bollixed up the direction of the coordinates or something :-)
One thing that I found confused me in copying and pasting is that I expected the pasted objects to appear at the mouse pointer location, rather than at the same ccordinates as in the window from which they were copied. While I could see the reason for this from a programming standpoint, I found it to be a problem, since quite often the paste happened outside the visible window. When that happened, until I caught on to what was happening, I sometimes pasted multiple copies, thinking that the first paste didn't work.)
maybe centering the pasted lump in the current viewed area of the patch...
On Thu, 27 Dec 2001 17:47:10 -0800 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
This is a good idea... I'll try to find a solution for pasting that behaves better...
cheers Miller
One thing that I found confused me in copying and pasting is that I expected the pasted objects to appear at the mouse pointer location, rather than at the same ccordinates as in the window from which they were copied. While I could see the reason for this from a programming standpoint, I found it to be a problem, since quite often the paste happened outside the visible window. When that happened, until I caught on to what was happening, I sometimes pasted multiple copies, thinking that the first paste didn't work.)
Miller Puckette hat gesagt: // Miller Puckette wrote:
This is a good idea... I'll try to find a solution for pasting that behaves better...
My vote for a good paste location:
I would like to control, where pasted objects go.
What if the pasted object[s] would hang at the mouse cursor the way new objects created with Ctrl-[1234] do? One could then place them where appropriate. The problem with pasting in PD is, that PD doesn't have a "real" cursor like text or audiofile editors have. And while text editors with their cursors have a natural place for paste inserts, PD doesn't have one.
To me the problem with the current solution is not only, that it is possible to paste outside of the visible area, but more this: If I click into the window after an unvisible paste, I unintendetly unselect the pasted object[s], which could lead to a mess, if the pasted objects lay over objects, that were already in the window.
I hope it is understandable, what I'm trying to say...
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
hi,
yes, this `sticky-paste' idea is very nice. The only design trouble left is this: where is the hot-spot? Upper-left corner of the topmost object? Or, maybe in a more standard way, upper-left corner of the smallest enclosing rectangle (but this would not guarantee preventing hidden pastes, which is the main reason of changing current pasting behaviour)?
For the time being, there is a very simple trick allowing full control over pasting position: select, duplicate, drag to any desirable place in a source window, cut, switch windows, and paste.
Krzysztof
Frank Barknecht wrote: ...
I would like to control, where pasted objects go.
What if the pasted object[s] would hang at the mouse cursor the way new objects created with Ctrl-[1234] do? One could then place them where appropriate.
...
-
Frank Barknecht -
Joseph Zitt -
Krzysztof Czaja -
Miller Puckette -
pix