Bugs item #1624229, was opened at 2006-12-29 03:10
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1624229&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: externals
Group: v0.39.2
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: IOhannes m zmölnig (zmoelnig)
Summary: msgfile busted
Initial Comment:
The msgfile does not work on the PowerPC: Pd-0.39.2-extended-test6-macosx104 release. And not on any of the previous macOSX releases under 39.2 either. Looks like it loads files fine, but it outputs only a done bang. Have tried to rewind etc. No luck. Just for the record.
T.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-03-05 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-02-20 07:46
Message:
Logged In: YES
user_id=564396
Originator: NO
please provide more information.
which file are you trying to load? which mode?
are you sure the file can be found?
and please use more descriptive wording than "busted"
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1624229&group_…
Bugs item #1844526, was opened at 2007-12-04 17:37
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1844526&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: externals
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: IOhannes m zmölnig (zmoelnig)
Summary: [msgfile]: loses content, when end reached (since 2.2.0)
Initial Comment:
the objectclass [msgfile] introduced a bug since version 2.2.0 of zexy. as soon as the last line of [msgfile]'s content is reached, the complete content is lost.
see attached patch.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-03-05 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-02-20 08:24
Message:
Logged In: YES
user_id=564396
Originator: NO
should be fixed in recent svn
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-12-05 01:37
Message:
Logged In: YES
user_id=564396
Originator: NO
took responsibility; thanks for the attached patch
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1844526&group_…
Bugs item #1528731, was opened at 2006-07-25 18:18
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1528731&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: externals
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: IOhannes m zmölnig (zmoelnig)
Summary: hex loader doesn't work with namespace prefixes
Initial Comment:
When using a hex loader name like 0x3c0x7e.pd for [<~],
you can't use namespace prefixes since the / is only
interpreted as a hex value 0x2f.
For example, [zexy/<~] tries to load only
zexy0x2f0x3c0x7e.pd, and therefore fails.
An additional search path should be added after this
one where the / is used literally without being
translated into a hex code, then it would look for
zexy/0x3c0x7e.pd
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-03-05 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-02-20 07:21
Message:
Logged In: YES
user_id=564396
Originator: NO
by calling the sys_load_lib recursively with the alternative names.
the only remaining problem is with abstractions (it turned out, that the
hexloader was not really able to load abstractions that contained other
abstractions - however, this should be in a different bug-ticket).
----------------------------------------------------------------------
Comment By: Mathieu Bouchard (matju)
Date: 2007-10-17 12:29
Message:
Logged In: YES
user_id=801174
Originator: NO
so, tell me, how do you make a pyext loader use the hex loader?
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-17 07:53
Message:
Logged In: YES
user_id=564396
Originator: NO
i just updated the hexloader external (which replaces the hexloader-code
in main pd) to do some special handling of "/".
(the revised hexloader-external is now also able to load abstractions!)
i have tested it under linux and os-x 10.4 (i think) with pd-0.41(os-x)
and pd-0.40 (linux);
could you please confirm and eventually close this bug?
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-16 02:48
Message:
Logged In: YES
user_id=564396
Originator: NO
how exactly do you think this should happen?
e.g. how should [path//] be resolved? "path0x2f0x2f.pd", "path/0x2f.pd",
"path0x2f/.pd" or "path//.pd"?
once there is a precise idea on how the problem should be solved, i can go
and implement it.
btw, i changed the category to "externals" since the hexloader is no
longer part of pd itself
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1528731&group_…
Hi all,
Thought this might be of interest to developers of OSC externals.
In short: Pd OSC implementations should send OSC on the same port that
they listen on, as that is the "standard" way OSC works.
Claude
-------- Original Message --------
Subject: Re: [sc-users] NetAddr
Date: Tue, 04 Mar 2008 21:48:37 -0500
From: nescivi
Reply-To: SuperCollider users mailing list <sc-users(a)create.ucsb.edu>
To: SuperCollider users mailing list <sc-users(a)create.ucsb.edu>
Hiho,
On Tuesday 04 March 2008 21:28:27 William Brent wrote:
> Hmm. I've been doing a little more testing on this, using two separate
> machines. Here's what seems to be true:
>
> 1) With both machines using SC, OSC messaging is fine through port 57120.
> Each side simply specifies
>
> n = NetAddr("address of other machine", 57120);
> o = OSCresponder(n, '/chat', { |t, r, msg| msg.postln }).add;
>
> n.sendMsg("/chat", "blah");
>
> This means each machine is listening for messages *from* the address of the
> other machine, on port 57120, and sending messages *to* the other addresss
> on port 57120.
>
> So within SC, of course, all is well.
correct, since SC sends from the same port as that it listens to, which
is as
it should be.
In OSC world it is custom to send reply messages, so from the received
message
you are able to figure out from which ip and port is was sent, so you can
back a message.
> 2) OSC communication between Max and Max, Pd and Pd, or Pd and Max is all
> fine.
>
> 3) Using either the sendOSC object in Pd, or the udpsend object in Max/MSP,
> communication with SC fails unless SC's OSCresponder addr argument is set
> to nil. This is in spite of the fact that sendOSC and udpsend require you
> to specify the address and port number you'd like to send *to*.
Again, there is a difference between the address they are sending from and
sending to. Like putting your address on a letter you send by snail
mail. It
gives the receiver a method to figure out where the letter came from, and
enables him to send a letter back.
> There is
> no way to specify what port you're sending *from* on the Pd or Max
> machines, but I've been told that if you're sending to a specific port on
> another machine, the local machine must necessarily be sending out the same
> port. I have no idea if that's true or not...
no.
The fact that there is no way to specify *from* which Pd or Max are
sending is
a weakness on their side. They should either let you specify it, or
document
which port they are using. But chances are that they just take any port, in
which case you have no other option than to use nil in the OSCresponder.
But maybe Max and Pd are consistent in their behaviour.
I am not entirely sure whether this will work, for lack of Pd on my system,
but possibly with this bit of code, you van figure out from which
address Pd
is sending.
o = OSCresponder(nil, '/chat', { |t, r, msg, addr| addr.postln; }).add;
I think it should post the addr. that the message comes from; please
test this
by banging your sendOSC object multiple times to see if it is consistent.
> So, in a way, there's no problem, as long as you explicitly specify no
> NetAddr to listen for. A friend of mine did a piece by Paul Lansky that
> required SC/Max communication, and that code also has OSCresponders
> listening to a "nil" NetAddr, since it was the only way to make it happen.
>
> I don't know enough about this to suggest what's going on. Maybe I'm still
> missing something (and sorry if I am!), but it seems like there could be a
> problem on the SC side here...
nope, the problem is on the other side.
SC allows for a safe mechanism by only listening to one specific port.
It is
up to the sending application to provide an equally safe mechanism to send
messages out.
sincerely,
Marije
_______________________________________________
sc-users mailing list
sc-users(a)create.ucsb.edu
http://lists.create.ucsb.edu/mailman/listinfo/sc-users
Bugs item #1601850, was opened at 2006-11-23 17:17
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1601850&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: externals
>Group: None
>Status: Pending
Resolution: None
Priority: 3
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: musil (tmusil)
Summary: [vcf_filter~] does not instantiate without arguments
Initial Comment:
Running Pd-0.39.2-extended-2006-11-23 on Mac OS X 10.4, when I instantiate [vcf_filter~] without any arguments, it crashes Pd.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-03-05 14:37
Message:
Logged In: YES
user_id=564396
Originator: NO
i think that this should be handled by Pd itself:
Pd knows that there _is_ an objectclass [vcf_filter~]. Pd then calls the
constructor of this objectclass which fails.
So Pd should be aware that this is not an "unfound" class but a class that
could not create for _other_ reasons.
in this case, Pd could expose the possibility to access the help-file even
though the object cannot create.
i have submitted feature-request #1907998 that asks for this.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-12-19 06:37
Message:
Logged In: YES
user_id=27104
Originator: YES
changed to reflect the updated situation
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-11-30 02:55
Message:
Logged In: YES
user_id=27104
Originator: YES
any chance of fixing it by setting a default value instead? Or maybe have
it instatiate but do nothing without an argument. I think it can be quite
confusing and annoying if you need an argument to instantiate. For
example, I often create an object to open the hlep patch. That wouldn't
work here.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-11-29 19:40
Message:
Logged In: YES
user_id=564396
Originator: NO
i have fixed this in CVS by replacing A_DEFSYM by A_SYMBOL in
vcf_filter~:323
this makes [vcf_filter~] refuse to create when no argument is given
instead of crashing pd
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1601850&group_…
Feature Requests item #1907998, was opened at 2008-03-05 14:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1907998&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: Open
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: give clues that object's constructor has failed
Initial Comment:
currently, when an object (that is: non-abstraction external) fails to create, this can be of 2 reasons:
- the objectclass is unknown (and cannot be found on the filesystem)
OR
- the objectclass is there, but the constructor has failed
both look the very same in the patch (a dashed box)
however, it would be nice if these could be distinguished on a patch-level, so the user have a clue what actually happened (without having to read pages of pd-console output)
i would suggest using a different colour for the two cases (e.g. grey out a known object that fails to construct)
additionally it would be nice to be able to access the right-click help of an objectclass if it failed to construct. (so people can get an idea what they did wrong)
it shouldn't be too hard to do, as Pd already has a notion of what happened.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1907998&group_…
Bugs item #1508221, was opened at 2006-06-18 20:45
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1508221&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: v0.41.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: dynamic patching locks up Pd and pegs CPU
Initial Comment:
When I work on this patch, it works fine. But when its
embedded in another patch as an object, it causes Pd to
stop responding and peg the CPU.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-03-05 13:53
Message:
Logged In: YES
user_id=564396
Originator: NO
btw, Pd hangs in g_editor.c:222 (glist_noselect() deselect-objects-loop)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1508221&group_…
Bugs item #1747117, was opened at 2007-07-03 15:24
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1747117&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Miller Puckette (millerpuckette)
Summary: [writesf~]: sr in header is hardcoded to 44100 for aiff
Initial Comment:
the flag '-rate' doesn't have any effect, when writing into aiff-files. a hardcoded value of 44100 is used instead. this value is defined in d_soundfile.c on line 700.
submitted by roman ( reduzierer at yahoo dot de )
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1747117&group_…
Bugs item #1853216, was opened at 2007-12-18 17:06
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1853216&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: v0.40.2
>Status: Pending
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: ClaudiusMaximus (claudiusmaximus)
>Assigned to: Miller Puckette (millerpuckette)
Summary: class_set_extern_dir not exported (breaks loaders)
Initial Comment:
The problem:
Help patches for externals loaded by the loader functionality of Pd are not found.
They can be found if class_set_extern_dir() is used, but this doesn't work on all platforms (unresolved symbol errors when trying to load the loader).
The solution:
Declare class_set_extern_dir() in m_pd.h and export it from pd/src/m_class.c or pd/src/s_loader.c .
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2008-01-14 19:58
Message:
Logged In: YES
user_id=313747
Originator: NO
Did it.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1853216&group_…