hi cyrille ...
i'm experiencing some problems with line ...
if i'm ramping from value a to value b, it's possible, that not value b
is reached, but another value ... it's a problem when a new ramp is
started, while another one is still active ....
i think this is a bug, since the value is going to exceed the requested
region.
would be great if you could have a look at it ...
thanks ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest mp3: kMW.mp3
http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone
http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs
Hallo!
> I'll start experimenting with that soon... but i'm going for a bit of
> vacation first.
of course - do that ... :)
LG
Georg
--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse f�r Mail, Message, More +++
Patches item #1060511, was opened at 2004-11-04 21:18
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1060511&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Pablo MartÃÂn (caedesv)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch for native alsa sequencer midi support
Initial Comment:
The patch allows pd to be connected to different
sources and sinks of midi messages through the alsa
sequencer natively.
It lets pd open 1 or more sequencer inputs or outputs.
Alsa midi support is selected at compile time, if alsa
headers are found alsa midi support will be compiled
instead of oss.
All midi events work ok, i think probably raw midi does
not.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2005-07-16 22:46
Message:
Logged In: YES
user_id=564396
seems to have made it into pd-0.39
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2005-07-11 18:56
Message:
Logged In: YES
user_id=564396
implemented a first version of runtime switching between
OSS-midi and ALSA-midi.
i haven't made all the various APIs switchable (as is with
audio), because it deemed me too much work...
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2005-07-11 17:00
Message:
Logged In: YES
user_id=564396
replaced s_midi_alsa.c with steve's version;
this allows more than 1 MIDI output-port (or device) (read:
more than 16 channels) and fixes [midiout]
----------------------------------------------------------------------
Comment By: steve (steve94075)
Date: 2005-06-28 07:46
Message:
Logged In: YES
user_id=1271013
i did a little tweaking of this patch and right now it works
on all 8 ports of my midisport8x8, plus sys_putmidibyte is
implemented, so [midiout] actually triggers midi instead of
an error message. it's a bit of a hack job, but it works
great for me (and hopefully you as well).
my modified version of s_midi_alsa.c can be found at
http://finkla.com/steve/s_midi_alsa.c
if anyone with power to update the files here on sourceforge
cares to, please do, but in any case that link should stay
alive for quite a while.
-steve
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2005-05-18 06:45
Message:
Logged In: YES
user_id=313747
I didn't look closely, but I think to do this right would
require
actually giving a run-time choice between ALSA and OSS MIDI
systems. A big job.
----------------------------------------------------------------------
Comment By: Guenter Geiger (ggeiger)
Date: 2005-05-02 11:16
Message:
Logged In: YES
user_id=430561
Here is the patch and s_midi_alsa.c file as I use it in the
Debian package currently. It seems that the author of the
patch does not have to time to update it, or probably he
just isn't aware of problems, so take it with a grain of
salt. Also we have to check for the multiple devices problem
steve.long
mentions.
Guenter
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2005-05-01 23:14
Message:
Logged In: NO
apparently [notein] for channels above 16 works as expected,
17-32 coming from the second device and so on, but [noteout]
only sends to the first device, chans 17-32 send to device 1
just like 1-16, as do 33-48, etc.
steve.long(a)camp.org
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2005-02-25 18:46
Message:
Logged In: YES
user_id=564396
this crashes my system if i don't have an alsa-sequencer
(e.g. no modules loaded)
----------------------------------------------------------------------
Comment By: Guenter Geiger (ggeiger)
Date: 2004-11-12 10:55
Message:
Logged In: YES
user_id=430561
there is a bug when no alsa devices are present (or if
they can't be opened). Attached addon patch fixes the problem.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1060511&group_…
Hallo!
> - rewrite the patch using a professional software of your choice (it
> would surprise me if supercollider isn't able to load soundfiles on the
> fly)
Yes, but also supercollider has disadvantages (as you might know) ... but
anyhow, I don't want a supercollider vs. pd discussion now :)
> - try pyext and numarrays
> - rewrite the threaded soundfiler :-)
what about a threaded soundfiler with flext (dont know if this would work) ?
then only thomas has the work to adpat it for the new pd releases ... :)
LG
Georg
--
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
Hallo!
>>So, there is no SConscript in extra/ (should there be one?) and
> oops ... now there is ;-)
okay - thanks ...
It compiles, but e.g. bonk etc. is missing:
...
scons: *** Source `extra/bonk~/bonk~.c' not found, needed by target
`extr/bonk~.os'. Stop.
scons: building terminated because of errors.
...
Also the manual, docs, ... are still missing (I know, you just started to
work on 0_39)
> well, i think this was a clash when using both the fftw and the threaded
> soundfiler ... i probably won't rewrite the threaded soundfiler for 0.39
> ... i rewrote it for 0.38 and would probably have to rewrite it for
> 0.40-1.00 ... and since there will be an array external working for
> xsample, vasp, py, that _will_ be threaded, why will pd need features
hm, I can understand you ...
anyhow, I need it for a specific patch, so should I stay with devel_0_38 or
are there any other workarounds in the meantime (besides upsampling and
readsf~ ...) ?
LG
Georg
PS: Is it a problem for you if I check in all the missing files (when I need
them) ?
--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse f�r Mail, Message, More +++
Hallo Tim!
Some other problems with scons:
I just checked out the devel_0_39 and:
<snip>
Checking for C header file tk.h... no
Checking for C header file tk/tk.h... no
Checking for C header file tk8.0/tk.h... no
Checking for C header file tk8.1/tk.h... no
Checking for C header file tk8.2/tk.h... no
Checking for C header file tk8.3/tk.h... no
Checking for C header file tk8.4/tk.h... no
Checking for C header file tk8.5/tk.h... no
Checking for C header file tk8.6/tk.h... no
Checking for C header file tk8.7/tk.h... no
Checking for C header file tk8.8/tk.h... no
Checking for C header file tk8.9/tk.h... no
Checking for C header file tcl8.0/tk.h... no
Checking for C header file tcl8.1/tk.h... no
Checking for C header file tcl8.2/tk.h... no
Checking for C header file tcl8.3/tk.h... no
Checking for C header file tcl8.4/tk.h... no
Checking for C header file tcl8.5/tk.h... no
Checking for C header file tcl8.6/tk.h... no
Checking for C header file tcl8.7/tk.h... no
Checking for C header file tcl8.8/tk.h... no
Checking for C header file tcl8.9/tk.h... no
can't find tk header
Checking for pthread_create() in C library pthread... yes
Checking for main() in C library fftw3f... no
Checking for dlopen() in C library dl... yes
Checking for jack_activate() in C library jack... yes
Checking for snd_pcm_info() in C library asound... yes
scons: warning: Ignoring missing SConscript 'extra/SConscript'
File "SConstruct", line 32, in ?
TypeError: iteration over non-sequence:
File "SConstruct", line 48:
for extra in extras:
</snip>
So, there is no SConscript in extra/ (should there be one?) and
unfortunately it doesn't find the tk headers again ... :(
Thanks,
LG
Georg
--
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
Patches item #1214164, was opened at 2005-06-03 12:48
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214164&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: route bug with zero-length lists ("bang") in float-mode
Initial Comment:
when sending a "bang" message [route] in float-mode
(e.g. [route 1 2]), the bang will silently vanish.
i think this is due to the fact, that now "bang"s are
equal to zero-length-lists which are discarded by the
route_list-method in float-mode.
anyhow, the attached patch (against pd-0.38-4) will
send the "bang" to the reject-outlet
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2005-07-16 15:38
Message:
Logged In: YES
user_id=564396
accepted into pd>=0.39
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2005-07-16 03:17
Message:
Logged In: YES
user_id=313747
Sounds right... so I took it...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214164&group_…
Patches item #1214166, was opened at 2005-06-03 12:51
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214166&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: complaining about [route] with mixed-type arguments
Initial Comment:
quoting the reference-patch of [route]:
"Route checks the first element of a message against
each of its
arguments, which may be numbers or symbols (but not a
mixture of the two.)"
however, creating [route 5 bla] is possible and no
hints are given that this is illegal.
attached is a patch that checks the creation arguments,
and if they are illegal, no object will be created
(with some verbosity, so the user knows what went wrong)
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2005-07-16 15:28
Message:
Logged In: YES
user_id=564396
fixed with pd>=0.39
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2005-07-16 03:02
Message:
Logged In: YES
user_id=313747
OK... I fixed it slightly differently though.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1214166&group_…
Patches item #1224730, was opened at 2005-06-21 11:04
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1224730&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
>Group: bugfix
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: pdsend bug with long(>127) sendbuffers
Initial Comment:
in pdsend the length of the buffer is limited to 4096
chars.
however, in the send-routine, the buffer-length is
evaluated into a variable of type "char";
this prohibits the sending of buffers where
(char)strlen(buf)<0 (easy to reach, when working with
buffers longer than 127 chars)
this behaviour appears in all versions of pd<=0.38-4 (i
guess)
attached is a patch that uses "unsigned int" for the
length instead of "char"
NOTE: i guess the correct type should rather be "size_t"
NOTE: i think pdsend/netsend (and pdreceive/netreceive)
should really use the same code rather than 2 separate
copies.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2005-07-16 15:24
Message:
Logged In: YES
user_id=564396
fixed with pd>=0.39
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2005-07-16 02:22
Message:
Logged In: YES
user_id=313747
Wow, that was stupid of me. Thanks for catching it. To
appear next CVS commit.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1224730&group_…
Patches item #1228872, was opened at 2005-06-28 11:12
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1228872&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: bugfix
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Miller Puckette (millerpuckette)
Summary: fix verbosity of iemgui's when changing send/receive-names
Initial Comment:
you can set the send/receive-names of the iemgui_s with
messages.
however, somebody has added some debugging output into
the code that does change the send-name, resulting in
following output to the console:
"send: before [newname], after [newname]"
while this does not affect the functionality, it fills
the console with messages that do not provide any realy
functionality.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2005-07-16 02:28
Message:
Logged In: YES
user_id=313747
That was my fault. Fixed now. -msp
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2005-06-28 11:14
Message:
Logged In: YES
user_id=564396
assigned to msp
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1228872&group_…