Bugs item #1818219, was opened at 2007-10-22 18:50
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1818219&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: stffn (stffn)
>Assigned to: Hans-Christoph Steiner (eighthave)
Summary: namespace prefix not included in save functions
Initial Comment:
1. Open the attahced patch in Pd-extended.
2. Notice the both [list-abs/wrandom] and [unauthorized/grid] gets created.
3. Save the patch whit out making any chages.
4. Close the patch.
5. CLose Pd-extended.
6. Open the patch again.
7. See that the grid objects doesn't get created and (since) the the prefix has been removed.
This happens in Pd-extended-0.39.3 mac intel.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-29 14:59
Message:
Logged In: YES
user_id=27104
Originator: NO
Thru this thread, we figured out the fix:
http://lists.puredata.info/pipermail/pd-dev/2007-10/009797.html
Here's how to get the whole classname in the save function:
static void entry_save(t_gobj *z, t_binbuf *b)
{
t_entry *x = (t_entry *)z;
t_symbol *classname =
atom_getsymbol(binbuf_getvec(x->x_obj.te_binbuf)),
binbuf_addv(b, "ssiisiiss", gensym("#X"),gensym("obj"),
x->x_obj.te_xpix, x->x_obj.te_ypix,
classname,
x->x_width, x->x_height, x->x_bgcolour, x->x_fgcolour);
binbuf_addv(b, ";");
}
I added this fix to these objects:
bbogart/popup/popup.c
ffext/tracker/tracker.c
footils/knob/knob.c
ggee/gui/button.c
ggee/gui/gcanvas.c
ggee/gui/image.c
ggee/gui/slider.c
ggee/gui/sliderh.c
ggee/gui/ticker.c
ggee/gui/toddle.c
ggee/gui/w_envgen.h
hcs/cursor.c
miXed/cyclone/hammer/Table.c
miXed/cyclone/hammer/comment.c
miXed/cyclone/hammer/funbuff.c
miXed/cyclone/sickle/Scope.c
miXed/toxy/widget.c
moonlib/gamme.c
moonlib/image.c
moonlib/mknob.c
pdvjtools/colorgrid/colorgrid.c
pdvjtools/imagegrid/imagegrid.c
pdvjtools/videogrid/videogrid.c
pidip/modules/pdp_colorgrid.c
unauthorized/audience~/audience~.c
unauthorized/cooled~/cooled~.c
unauthorized/exciter/exciter.c
unauthorized/filterbank~/filterbank~.c
unauthorized/grid/grid.c
unauthorized/pianoroll/pianoroll.c
unauthorized/probalizer/probalizer.c
unauthorized/scratcher~/scratcher~.c
unauthorized/scrolllist/scrolllist.c
unauthorized/sonogram~/sonogram~-joge.c
unauthorized/sonogram~/sonogram~-yves.c
unauthorized/sonogram~/sonogram~.c
That leaves the code in externals/iem, pd/src/, and some of the more
complex objects in externals/miXed.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-26 23:32
Message:
Logged In: NO
yeah, because of the m_imp.h inclusion, this is a problem. it could be
solved by adding a function to m_pd.h that returns the class name as a
symbol or C string, whichever is more convenient. i think that it's much
easier than changing the interface.
otherwise, you could make another class_setsavefn that would register the
fact that you want the 5 atoms "#X" "obj" x1 y1 classname to be written
before the savefn is called. The original has to be kept both because of
backward-compatibility and because it's possible to make externals that
have a subpatch-like behaviour (though no-one has tried doing that yet!)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-26 12:12
Message:
Logged In: YES
user_id=27104
Originator: NO
If every patch is going to add (*(t_pd *)x)->c_name->s_name to the savefn,
then it seems to me that there should be a mechanism in Pd itself to do
this automatically. Then the interface might need to be different.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-25 21:14
Message:
Logged In: NO
hans, it's not the meaning of t_savefn itself that has to be changed: it's
just every use t_savefn, that is, every blah_savefn function that gets
registered, if they aren't already using (*(t_pd *)x)->c_name->s_name.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-25 13:24
Message:
Logged In: YES
user_id=27104
Originator: NO
This sounds like an excellent idea! I think that this improved savefn
will probably need to be distinct from the current savefn stuff, since it
probably wouldn't be compatible. But if it could be the same mechanism,
that would be even better.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2007-10-24 05:42
Message:
Logged In: YES
user_id=564396
Originator: NO
i changed the category, since it is a problem with pd (though it affects
externals)
i changed the name, because it is not gui-specific: every object that
defines a savefn() is affected by this (usually only gui-classes do this
because they are the classes where you cannot directly edit the arguments
(being hidden) and which might offer a properties window to change these
arguments)
however: i think it is a great feature that an object is able to change
it's own name (really).
nevertheless, an object should also be able to _query_ it's own name.
this is usually not a big problem because the object assumes that it knows
how it is called (the name the dev gave it).
when using namespaces this is not the case any more.
basically: the object would need a way to easily query it's own name (i am
sure it is somehow possible via weird t_canvas/t_class/t_obj/t_pd/...
pointer magic which is so complicated i will have to re-read to source
code)
the savefn() should provide a way to set object-name and arguments
separately, the object-name should default to the actual name (not the
canonical one) if not set otherwise.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-23 20:50
Message:
Logged In: YES
user_id=27104
Originator: NO
I found the root of the problem, if the GUI object has a savefn, then that
savefn needs to include the whole classname, including the namespace
prefix.
I think stffn was right, it does apply to all GUIs.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-23 17:09
Message:
Logged In: YES
user_id=27104
Originator: NO
This doesn't happen to all GUI objects, just some. I think [grid] is one,
but many others work fine with the prefixes.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-23 03:44
Message:
Logged In: YES
user_id=1658640
Originator: YES
True, this also happens in Pd version 0.40-2.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-22 19:40
Message:
Logged In: YES
user_id=27104
Originator: NO
This happens on Pd-0.40.3-extended-20071021 on Mac OS X also. Has anyone
tested this on other GOPs? I know pddp/pddplink works fine. Also
cyclone/Scope~ also works. I think this might be an issue with the objects
themselves.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-22 18:52
Message:
Logged In: YES
user_id=1658640
Originator: YES
I forgot to mention that it happens to quite many if not all the GUI
objects. At least those in CVSROOT/doc/pddp/about/GUIs-about.pd.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1818219&group_…
Patches item #1822220, was opened at 2007-10-29 13:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822220&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: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: include PDP MMX support, and turn on compiler optimizatons
Initial Comment:
There is a whole suite of functions written MMX assembler for MMX. This should be enabled in the x86 PDP builds in Pd-extended.
Also, it would be worthwhile to try the gcc 4.1 compiler optimizations
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822220&group_…
Patches item #1822010, was opened at 2007-10-29 11:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822010&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: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: hardcoded sample-type in soundfile-IO
Initial Comment:
the current implementation in d_soundfile.c assumes that both t_sample and t_float are "float".
this is not necessarily true.
additionally it assumes that typeof(t_sample) and typeof(t_float) are identically.
this is not necessarily true.
based on the assumption that (number)arrays are of type t_float and signals are of type t_sample, the attached patch provides 2 extra functions for xferin/xferout that use different types for reading/writing soundfiles.
basically it provides:
soundfile_xferin_sample() (reading soundfile to signal)
soundfile_xferin_float() (reading soundfile to table)
soundfile_xferout_sample() (writing soundfile from signal)
soundfile_xferout_float() (writing soundfile from table)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822010&group_…
Patches item #1822007, was opened at 2007-10-29 11:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822007&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: Open
Resolution: None
Priority: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: hardcoded sample-type in jack-transport
Initial Comment:
in s_audio_jack.c the sample-type of the jack transportlayer is assumed to be "float", which is a naive assumption.
the correct type is "jack_default_audio_sample_t" (which might be either "float" or "double", depending on how jack was compiled)
the attached patch respects the type-definition of both jack and pd's own t_sample.
when the 2 types are the same, it just does a memcpy (this is similar as before, where it is assumed that both jack and pd use "float" internally)
when they are different, it copies the data manually.
LATER: improve the heuristic for finding out whether the two types are equal (currently only the sizeof() is checked)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822007&group_…
Patches item #1822001, was opened at 2007-10-29 11:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822001&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: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: use of t_float/t_sample instead of "float"
Initial Comment:
i am currently trying to build a Pd which is based on "double" instead of "float".
in m_pd.h there are special types defined "t_sample" (for signals) and "t_float" (for messages).
in theory this makes it simple to switch between different precisions (e.g. "float" vs. "double") in both the signal and the message domain (independently).
unfortunately, in practice this does not work, because the special types are not always used (in fact, the code seems to refer more often to the types "float" instead of "t_float"/"t_sample").
the attached patch changes the occurences of "float" to "t_float" or "t_sample", depending on the context:
- t_sample is only used for signals
- t_float is used for messages
note#1: for CLASS_MAINSIGNALIN i use t_float instead of t_sample (the original code suggested t_sample instead); this makes more sense to me, as we are really dealing with messages(!), which eventually become samples
note#2: this patch only deals with trivial changes from "float" to "t_float"/"t_sample". i have not touched all the float-magic that is used in d_osc yet
note#3: the tgz contains patches for each file separately. this is to make reading easier...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822001&group_…
Bugs item #1821847, was opened at 2007-10-28 19:12
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&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.39.2
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: writesf~ doesn't write sound to files
Initial Comment:
I have been wrestling with tracking down why my Swirler program won't record audio. Most of the time, when I try to use [writesf~] to record, it does not work at all. It creates the file when I send the open message, and I get a file of 44 bytes, then when I click start, and then stop, the file does not change.
Occasionally, it will record about 1-2 seconds of material, no matter when I hit stop. Very occasionally, it will work fine on its own.
I tried also with the writesf~ help patch, as well as others. It seems that my program Swirler stops writesf~ from working anywhere. writesf~ works fine until I run Swirler and click the "start" button, which turns on the DSP and starts the audio processing part.
This is currently happening on Mac Book Pro/Intel running 10.4.10 with Pd-0.40-2, Pd-0.39.3-extended, and Pd-0.40.3-extended-20071026. This happened previously with Pd-0.39.3-extended-rc? on a PowerMac G5/PowerPC running Mac OS X 10.4.8(ish).
I compiled Pd with DEBUG_SOUNDFILE on to see if I could see what's happening. You can plainly see it's not writing data to the file. I found a strange workaround sequence that makes it record, but then the write cycle is strange, it goes in bursts every few seconds rather than a chunk every second.
I attached the swirler program and some transcripts from teh DEBUG_SOUNDFILE stuff.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:41
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: writesf~-bug.pd
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:40
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: writesf~-bug_after_swirlrer-1.txt
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:39
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: swirler-2007-10-28.tar.bz2
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:37
Message:
Logged In: YES
user_id=27104
Originator: YES
I forgot to include the strange workaround sequence:
1) turn on DSP
2) turn on record switch (start recording)
3) turn off record switch (stop recording)
4) turn on record switch (start recording again)
5) turn on START switch in swirler
6) make recording
7) turn off record switch (stop recording)
8) turn off START switch in swirler
The turn off order seems important too.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:13
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: writesf~-bug_working.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&group_…
Bugs item #1821847, was opened at 2007-10-28 19:12
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&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.39.2
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: writesf~ doesn't write sound to files
Initial Comment:
I have been wrestling with tracking down why my Swirler program won't record audio. Most of the time, when I try to use [writesf~] to record, it does not work at all. It creates the file when I send the open message, and I get a file of 44 bytes, then when I click start, and then stop, the file does not change.
Occasionally, it will record about 1-2 seconds of material, no matter when I hit stop. Very occasionally, it will work fine on its own.
I tried also with the writesf~ help patch, as well as others. It seems that my program Swirler stops writesf~ from working anywhere. writesf~ works fine until I run Swirler and click the "start" button, which turns on the DSP and starts the audio processing part.
This is currently happening on Mac Book Pro/Intel running 10.4.10 with Pd-0.40-2, Pd-0.39.3-extended, and Pd-0.40.3-extended-20071026. This happened previously with Pd-0.39.3-extended-rc? on a PowerMac G5/PowerPC running Mac OS X 10.4.8(ish).
I compiled Pd with DEBUG_SOUNDFILE on to see if I could see what's happening. You can plainly see it's not writing data to the file. I found a strange workaround sequence that makes it record, but then the write cycle is strange, it goes in bursts every few seconds rather than a chunk every second.
I attached the swirler program and some transcripts from teh DEBUG_SOUNDFILE stuff.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:40
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: writesf~-bug_after_swirlrer-1.txt
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:39
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: swirler-2007-10-28.tar.bz2
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:37
Message:
Logged In: YES
user_id=27104
Originator: YES
I forgot to include the strange workaround sequence:
1) turn on DSP
2) turn on record switch (start recording)
3) turn off record switch (stop recording)
4) turn on record switch (start recording again)
5) turn on START switch in swirler
6) make recording
7) turn off record switch (stop recording)
8) turn off START switch in swirler
The turn off order seems important too.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:13
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: writesf~-bug_working.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&group_…
Bugs item #1821847, was opened at 2007-10-28 19:12
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&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.39.2
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: writesf~ doesn't write sound to files
Initial Comment:
I have been wrestling with tracking down why my Swirler program won't record audio. Most of the time, when I try to use [writesf~] to record, it does not work at all. It creates the file when I send the open message, and I get a file of 44 bytes, then when I click start, and then stop, the file does not change.
Occasionally, it will record about 1-2 seconds of material, no matter when I hit stop. Very occasionally, it will work fine on its own.
I tried also with the writesf~ help patch, as well as others. It seems that my program Swirler stops writesf~ from working anywhere. writesf~ works fine until I run Swirler and click the "start" button, which turns on the DSP and starts the audio processing part.
This is currently happening on Mac Book Pro/Intel running 10.4.10 with Pd-0.40-2, Pd-0.39.3-extended, and Pd-0.40.3-extended-20071026. This happened previously with Pd-0.39.3-extended-rc? on a PowerMac G5/PowerPC running Mac OS X 10.4.8(ish).
I compiled Pd with DEBUG_SOUNDFILE on to see if I could see what's happening. You can plainly see it's not writing data to the file. I found a strange workaround sequence that makes it record, but then the write cycle is strange, it goes in bursts every few seconds rather than a chunk every second.
I attached the swirler program and some transcripts from teh DEBUG_SOUNDFILE stuff.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:39
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: swirler-2007-10-28.tar.bz2
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:37
Message:
Logged In: YES
user_id=27104
Originator: YES
I forgot to include the strange workaround sequence:
1) turn on DSP
2) turn on record switch (start recording)
3) turn off record switch (stop recording)
4) turn on record switch (start recording again)
5) turn on START switch in swirler
6) make recording
7) turn off record switch (stop recording)
8) turn off START switch in swirler
The turn off order seems important too.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:13
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: writesf~-bug_working.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&group_…
Bugs item #1821847, was opened at 2007-10-28 19:12
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&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.39.2
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: writesf~ doesn't write sound to files
Initial Comment:
I have been wrestling with tracking down why my Swirler program won't record audio. Most of the time, when I try to use [writesf~] to record, it does not work at all. It creates the file when I send the open message, and I get a file of 44 bytes, then when I click start, and then stop, the file does not change.
Occasionally, it will record about 1-2 seconds of material, no matter when I hit stop. Very occasionally, it will work fine on its own.
I tried also with the writesf~ help patch, as well as others. It seems that my program Swirler stops writesf~ from working anywhere. writesf~ works fine until I run Swirler and click the "start" button, which turns on the DSP and starts the audio processing part.
This is currently happening on Mac Book Pro/Intel running 10.4.10 with Pd-0.40-2, Pd-0.39.3-extended, and Pd-0.40.3-extended-20071026. This happened previously with Pd-0.39.3-extended-rc? on a PowerMac G5/PowerPC running Mac OS X 10.4.8(ish).
I compiled Pd with DEBUG_SOUNDFILE on to see if I could see what's happening. You can plainly see it's not writing data to the file. I found a strange workaround sequence that makes it record, but then the write cycle is strange, it goes in bursts every few seconds rather than a chunk every second.
I attached the swirler program and some transcripts from teh DEBUG_SOUNDFILE stuff.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:37
Message:
Logged In: YES
user_id=27104
Originator: YES
I forgot to include the strange workaround sequence:
1) turn on DSP
2) turn on record switch (start recording)
3) turn off record switch (stop recording)
4) turn on record switch (start recording again)
5) turn on START switch in swirler
6) make recording
7) turn off record switch (stop recording)
8) turn off START switch in swirler
The turn off order seems important too.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:13
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: writesf~-bug_working.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&group_…
Bugs item #1821847, was opened at 2007-10-28 19:12
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&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.39.2
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: writesf~ doesn't write sound to files
Initial Comment:
I have been wrestling with tracking down why my Swirler program won't record audio. Most of the time, when I try to use [writesf~] to record, it does not work at all. It creates the file when I send the open message, and I get a file of 44 bytes, then when I click start, and then stop, the file does not change.
Occasionally, it will record about 1-2 seconds of material, no matter when I hit stop. Very occasionally, it will work fine on its own.
I tried also with the writesf~ help patch, as well as others. It seems that my program Swirler stops writesf~ from working anywhere. writesf~ works fine until I run Swirler and click the "start" button, which turns on the DSP and starts the audio processing part.
This is currently happening on Mac Book Pro/Intel running 10.4.10 with Pd-0.40-2, Pd-0.39.3-extended, and Pd-0.40.3-extended-20071026. This happened previously with Pd-0.39.3-extended-rc? on a PowerMac G5/PowerPC running Mac OS X 10.4.8(ish).
I compiled Pd with DEBUG_SOUNDFILE on to see if I could see what's happening. You can plainly see it's not writing data to the file. I found a strange workaround sequence that makes it record, but then the write cycle is strange, it goes in bursts every few seconds rather than a chunk every second.
I attached the swirler program and some transcripts from teh DEBUG_SOUNDFILE stuff.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-10-28 19:13
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: writesf~-bug_working.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1821847&group_…