On 04/05/2011 01:14 AM, Hans-Christoph Steiner wrote:
'undefined reference' generally means that the linker has found
symbols
in the .o files that it can't find a reference to. I.e. take the
function 'foo', if myobject.o uses foo() from the bar lib, and the
bar
lib is not
It probably happens when you get two keydowns in the space of one Pd event
loop. The second is output at the same time. The same thing happens with
[metro] banging serial data into [comport] or [midiout]. The metro rate is
quantized to the event loop rate, so individual bangs are irregularly
Yes, the OS also has its own event loop, which might be more responsible for
that kind of timing, as it isn't running at a fixed rate and keyboard is
probably a lower priority than mouse or network events.
Martin
Ico wrote:
Many thanks for the explanation! What seems weird, however, is how
I just committed to svn a check for valid handle before any write can happen.
Strange that it didn't give errors before though, the handle would be -1.
Martin
hc wrote:
I'm just trying out the new comport object in trunk, and it seems that
it no longer outputs an error when you try to send
Hi Michal,
I don't think it's any bug with Pd, it's just that you are suffering from
dropped packets. The packets are sent by UDP, which sends each packet once and
forgets about it, unlike TCP which checks that the other end actually received
the packet and resends as necessary.
So it seems
ben wrote:
...
So that worked for getting the proper value, but the method I was using
to get the second argument (argv+1) no longer works. Presumably because
the next location is no longer the same.
...
Do you mean after you copied the data? Did you try either
threadargs-argv[1]
or
That's because atom_getint() wants a pointer to an atom, not the atom itself.
Try:
intValue = atom_getint(((gphoto_gimme_struct *)threadArgs)-argv+1);
or:
intValue = atom_getint(((gphoto_gimme_struct *)threadArgs)-argv[1]);
Martin
ben wrote:
Yes after copying.
gcc does not like either,
So what have I misunderstood?
argv is a pointer, it's size is 4. You're still not copying whatever argv is
pointing to.
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
I don't think sysex works on linux either; at least I'm trying to send using
[midiout] using alsa midi and nothing is going through the interface, whereas
[noteout] works fine. On Pd 0.42.5-extended2010105 debian lenny.
I think I should be able to send a list like:
[240 88 123 247(
|
[midiout]
On linux with alsa midi, sysex output works this way:
bang
|
[t b b b b]
| | | |
[247( [123( [88( [240(
|_|_||
|
|
[midiout]
That is, banging all the values separately into [midiout] during one message
time slot.
(Note the message is written backwards
hans wrote:
Hey all,
I know there are some of you who use MSVC. We are finalizing the new
Makefile template, if you want to include MSVC rules in it, now would
be the time to do it. Here's how: edit externals/ext13/Makefile and
add the stuff for MSVC. The key part is that it
hans wrote:
On Oct 4, 2009, at 9:19 PM, András Murányi wrote:...
Cool. We're here now:
cc -DPD -I/home/muranyia/Download/0.41/pd/src -Wall -W -ggdb
-I/home/muranyia/Download/0.41/Gem/src
-I/home/muranyia/Download/0.41/externals/pdp/include -DUNIX -Dunix -DDL_OPEN
-fPIC
The latest autobuild for windows
http://autobuild.puredata.info/auto-build/latest/Pd-0.42.5-extended-windowsxp-i386.exe
now installs pd.a as pd.lib and that seems to work OK to link against with
MSVisualC++2008ExpressEdition, so the .def file that is also installed is
probably redundant.
I
You need to install the fftw3-dev package.
Martin
muranyia wrote:
# sudo make install
...
cc -DPD -I/home/muranyia/Download/0.41/pd/src -Wall -W -ggdb
-I/home/muranyia/Download/0.41/Gem/src
-I/home/muranyia/Download/0.41/externals/pdp/include -DUNIX -Dunix -DDL_OPEN
-fPIC -O2
Well I'm trying to get rid of the bugs in it...
I don't get that on WinXP though (Pd 0.41.4-extended). I set the buffer to 12
and still received 30 bytes.
On Debian with Pd 0.41.4-extended I get two separate messages (each longer than
12) but still all the data arrives.
Martin
From:
IOhannes m zmoelnig wrote:
another question:
in osc, timetags are per-bundle (not per message).
is the scheduling information sent to the outlet for each message or
only once for each bundle?
The delay is output exactly once for each time tag. packOSC generates a time
tag whenever a bundle
Martin Peach wrote:
IOhannes m zmoelnig wrote:
nevertheless i think it might be very good if i could distinguish
between the 3 types of timetags)
That's a difficult problem. What's the difference between zero and zero?
I mean how does one tag no delay as being different from a
Hans-Christoph Steiner wrote:
Martin Peach wrote:
IOhannes m zmoelnig wrote:
OK, I changed packOSC to output negative delays and it's now
Oops, that should say unpackOSC...
obvious, even on the same machine a current time tag always has a
slight negative delay, whereas an
Is there a correct way to use diff to make the paths properly in the first
place? Do you have to run it from a particular location or specify a path?
Also I agree that string should be blob (or puredata ;)) since string implies
text and it's really able to manipulate any kind of byte data.
They all seem to be directly manipulating the exponent field of a float to
make/access lookup tables for every possible exponent. Is this necessary now
that everybody has floating-point units built-in to their processors? I can see
that it would be a big speed enhancer in a 386 or 68000 but the
You mean the labels?
In g_all_guis.c:
void iemgui_label(void *x, t_iemgui *iemgui, t_symbol *s)
and
void iemgui_label_pos(void *x, t_iemgui *iemgui, t_symbol *s, int ac, t_atom
*av)
The x_lab and y_lab items can be set in u_main.tk, they are the x_off and y_off
parameters for some of the guis.
Mathieu Bouchard [EMAIL PROTECTED] wrote:
Do you realise that the quoting problem can be solved independently of the
allocation problem? In that case, you would be able to save any symbol and
read it back. This would solve the problem about CR LF and spaces; only
the problem with \0
De: Hans-Christoph Steiner [EMAIL PROTECTED]
Date: 2006/12/18 lun. AM 09:45:26 GMT-05:00
À: carmen [EMAIL PROTECTED]
Cc: pd-dev@iem.at
Objet: Re: [PD-dev] strings
On Dec 18, 2006, at 1:23 AM, carmen wrote:
Automatic type conversion sounds like a really bad idea if the
language
De: Mathieu Bouchard [EMAIL PROTECTED]
Date: 2006/12/18 lun. PM 12:11:18 GMT-05:00
À: Martin Peach [EMAIL PROTECTED]
Cc: pd-dev@iem.at
Objet: Re: [PD-dev] strings
On Sun, 17 Dec 2006, Martin Peach wrote:
You make them work as strings when they can, and
You make them work as
I get:
if(argc 2)
on line 420, so I don't get it...
But whatever it really is, go ahead and change it if you think it works.
Martin
De: IOhannes m zmoelnig [EMAIL PROTECTED]
Date: 2006/12/11 lun. PM 12:55:42 GMT-05:00
À: pd-dev pd-dev@iem.at
Objet: [PD-dev] mrpeach/net/tcpserver
i
25 matches
Mail list logo
