Dear List, I am trying to make a video mixing type patch and am recording videos and naming them based on numbers spat out by the [time] object at the time of recording.
Then I want to recall them for play back with something like
[time] [][-2][] [set open $1.mov(
and pipe that to pix_film, but pix_film tells me:
error: [pix_filmDarwin]: unable to find file: ÿAK
I can see its a type casting issue but from what to what?
sorry if this is completely obvious and thank you for your attention,
Sofy
On Fri, 18 Mar 2011, sonia yuditskaya wrote:
[time] [][-2][] [set open $1.mov(
I don't know what you mean when you write [][-2][].
and pipe that to pix_film, but pix_film tells me: error: [pix_filmDarwin]: unable to find file: ÿAK I can see its a type casting issue but from what to what?
I first thought that there might be a bug with printing the error message, because I found that Gem has one or more similar bugs. Inside of the source code of [pix_filmDarwin] the error message above is printed by this command :
error("unable to find file: %#s", theFSSpec.name);
But when looking at the programming manual of MacOSX 10.4 for what %#s means, it says that %#s has no meaning ("#" would mean nothing when used together with "s").
So, I don't know what %#s is supposed to be doing there, and whether it means that theFSSpec.name is printed in the console in the wrong way or what.
I know that in some places, Gem does (or used to do) :
error("blahblah: %s", name);
instead of :
error("blahblah: %*s", *name, name+1);
and that it caused weird stuff to appear in the console when I got those errors, but it's normally a lot less garbled than what you've got : I could really see the filename, prefixed by one unwanted character, and suffixed by possibly a bunch of unwanted characters.
However, when I look at what theFSSpec.name is supposed to be in the error message, it looks like it's part of the same problem.
You could write that in Gem's bug tracker, with the title : « Gem tries to print Str63 and/or Str255 as if they were ordinary C Strings » and then write that one example of this bug is in "Unable to find file".
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
solved the problem by sending variables to the [seek $1( message in the [unauthorized/playlist] object and feeding that to the [open $1( of [pix_film]
don't why that works and the other one doesn't though.
bug submitted.
Sofy
On Fri, Mar 18, 2011 at 10:15 PM, Mathieu Bouchard matju@artengine.cawrote:
On Fri, 18 Mar 2011, sonia yuditskaya wrote:
[time]
[][-2][] [set open $1.mov(
I don't know what you mean when you write [][-2][].
and pipe that to pix_film, but pix_film tells me:
error: [pix_filmDarwin]: unable to find file: ÿAK I can see its a type casting issue but from what to what?
I first thought that there might be a bug with printing the error message, because I found that Gem has one or more similar bugs. Inside of the source code of [pix_filmDarwin] the error message above is printed by this command :
error("unable to find file: %#s", theFSSpec.name);
But when looking at the programming manual of MacOSX 10.4 for what %#s means, it says that %#s has no meaning ("#" would mean nothing when used together with "s").
So, I don't know what %#s is supposed to be doing there, and whether it means that theFSSpec.name is printed in the console in the wrong way or what.
I know that in some places, Gem does (or used to do) :
error("blahblah: %s", name);
instead of :
error("blahblah: %*s", *name, name+1);
and that it caused weird stuff to appear in the console when I got those errors, but it's normally a lot less garbled than what you've got : I could really see the filename, prefixed by one unwanted character, and suffixed by possibly a bunch of unwanted characters.
However, when I look at what theFSSpec.name is supposed to be in the error message, it looks like it's part of the same problem.
You could write that in Gem's bug tracker, with the title : « Gem tries to print Str63 and/or Str255 as if they were ordinary C Strings » and then write that one example of this bug is in "Unable to find file".
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sat, 19 Mar 2011, sonia yuditskaya wrote:
solved the problem by sending variables to the [seek $1( message in the [unauthorized/playlist] object and feeding that to the [open $1( of [pix_film] don't why that works and the other one doesn't though. bug submitted.
I wrote all the details I wrote to you, in your bug report.
BTW, the bug report I wanted to submit was about the error message, because that's the problem I know about, and without a good error message, it's hard to find whether [pix_film] has any real problem with the filename you give it. Thus $1 is not relevant in that bug report. But that's no big deal, because I posted all the details.
BTW, doesn't [pix_film] require the full name of the movie ? It doesn't seem to be accepting filenames that are relative to the patch's folder, nor to the items in the Path's dialogue.
[gf/find_file] finds a file and gives you the full filename. see http://gridflow.ca/ for that external.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Sorry, if I miss-filed the report (never filed one before).
To re-phrase the problem; [pix_film] would neither accept filenames with a $1 in them or a %s. In my case [pix_film] has consistently accepted filenames relative to the patch's folder, relative to Path however I have had no such success. Despite numerous attempts I've never been able to compile/download and have form gridflow, so cannot check that.
Hope despite the sparseness of detail, this illuminates something in someone's experience to draw the problem out? Being able to algorithmically recall files through [pix_film] would be a useful feature in designing real-time, interactive, video based, systems (pick your favorite buzzword ;)
in simulacra we trust, ] yuditskaya.com [
On Sat, Mar 19, 2011 at 12:41 AM, Mathieu Bouchard matju@artengine.cawrote:
On Sat, 19 Mar 2011, sonia yuditskaya wrote:
solved the problem by sending variables to the [seek $1( message in the
[unauthorized/playlist] object and feeding that to the [open $1( of [pix_film] don't why that works and the other one doesn't though. bug submitted.
I wrote all the details I wrote to you, in your bug report.
BTW, the bug report I wanted to submit was about the error message, because that's the problem I know about, and without a good error message, it's hard to find whether [pix_film] has any real problem with the filename you give it. Thus $1 is not relevant in that bug report. But that's no big deal, because I posted all the details.
BTW, doesn't [pix_film] require the full name of the movie ? It doesn't seem to be accepting filenames that are relative to the patch's folder, nor to the items in the Path's dialogue.
[gf/find_file] finds a file and gives you the full filename. see http://gridflow.ca/ for that external.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
I algorithmically generated and loaded files into pix_film on OSX millions and millions of times using 'open $1' without error. It would be helpful to see what your filenames look like.
On Sat, Mar 19, 2011 at 6:46 AM, sonia yuditskaya marysghost@gmail.comwrote:
Sorry, if I miss-filed the report (never filed one before).
To re-phrase the problem; [pix_film] would neither accept filenames with a $1 in them or a %s. In my case [pix_film] has consistently accepted filenames relative to the patch's folder, relative to Path however I have had no such success. Despite numerous attempts I've never been able to compile/download and have form gridflow, so cannot check that.
Hope despite the sparseness of detail, this illuminates something in someone's experience to draw the problem out? Being able to algorithmically recall files through [pix_film] would be a useful feature in designing real-time, interactive, video based, systems (pick your favorite buzzword ;)
in simulacra we trust, ] yuditskaya.com [
On Sat, Mar 19, 2011 at 12:41 AM, Mathieu Bouchard matju@artengine.cawrote:
On Sat, 19 Mar 2011, sonia yuditskaya wrote:
solved the problem by sending variables to the [seek $1( message in the
[unauthorized/playlist] object and feeding that to the [open $1( of [pix_film] don't why that works and the other one doesn't though. bug submitted.
I wrote all the details I wrote to you, in your bug report.
BTW, the bug report I wanted to submit was about the error message, because that's the problem I know about, and without a good error message, it's hard to find whether [pix_film] has any real problem with the filename you give it. Thus $1 is not relevant in that bug report. But that's no big deal, because I posted all the details.
BTW, doesn't [pix_film] require the full name of the movie ? It doesn't seem to be accepting filenames that are relative to the patch's folder, nor to the items in the Path's dialogue.
[gf/find_file] finds a file and gives you the full filename. see http://gridflow.ca/ for that external.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Those particular error messages often return gibberish for the
filename. I wonder why the error message doesn't use the char*
filename:
error("Unable to find file: %#s", theFSSpec.name);
Perhaps the functions above don't put data into .name if it can't find
a file. Anyone object if I change them to use 'filename' instead of
theFSSpec.name?
.hc
On Mar 19, 2011, at 10:42 AM, chris clepper wrote:
I algorithmically generated and loaded files into pix_film on OSX
millions and millions of times using 'open $1' without error. It
would be helpful to see what your filenames look like.On Sat, Mar 19, 2011 at 6:46 AM, sonia yuditskaya <marysghost@gmail.com
wrote:
Sorry, if I miss-filed the report (never filed one before).
To re-phrase the problem; [pix_film] would neither accept filenames
with a $1 in them or a %s. In my case [pix_film] has consistently
accepted filenames relative to the patch's folder, relative to Path
however I have had no such success. Despite numerous attempts I've
never been able to compile/download and have form gridflow, so
cannot check that.Hope despite the sparseness of detail, this illuminates something in
someone's experience to draw the problem out? Being able to
algorithmically recall files through [pix_film] would be a useful
feature in designing real-time, interactive, video based, systems
(pick your favorite buzzword ;)in simulacra we trust, ] yuditskaya.com [
On Sat, Mar 19, 2011 at 12:41 AM, Mathieu Bouchard
matju@artengine.ca wrote: On Sat, 19 Mar 2011, sonia yuditskaya wrote:solved the problem by sending variables to the [seek $1( message in
the [unauthorized/playlist] object and feeding that to the [open
$1( of [pix_film] don't why that works and the other one doesn't
though. bug submitted.I wrote all the details I wrote to you, in your bug report.
BTW, the bug report I wanted to submit was about the error message,
because that's the problem I know about, and without a good error
message, it's hard to find whether [pix_film] has any real problem
with the filename you give it. Thus $1 is not relevant in that bug
report. But that's no big deal, because I posted all the details.BTW, doesn't [pix_film] require the full name of the movie ? It
doesn't seem to be accepting filenames that are relative to the
patch's folder, nor to the items in the Path's dialogue.[gf/find_file] finds a file and gives you the full filename. see http://gridflow.ca/ for that external.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray,
Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
On Sat, 19 Mar 2011, sonia yuditskaya wrote:
To re-phrase the problem; [pix_film] would neither accept filenames with a $1 in them or a %s.
No, [pix_film] does accept any symbol. Once the $1 has been processed by the messagebox, it is no longer a $1 (in the output of the messagebox).
And the %s is something else, it's only when processing the error message so that it states the filename so that you can know that the symbol has been understood properly. The error() command in pd's internals works somewhat like [makefilename] (though error() supports a lot more options).
In my case [pix_film] has consistently accepted filenames relative to the patch's folder,
Yeah, that was my mistake.
relative to Path however I have had no such success.
That might be a GridFlow-only feature and I didn't remember it. (?)
Despite numerous attempts I've never been able to compile/download and have form gridflow, so cannot check that.
I don't recall reading about your numerous attempts. Did you post about any of them ? In any case, there have been ready-to-use GridFlow packages for OSX for over a year and we have put a lot of hours in preparing them.
Hope despite the sparseness of detail, this illuminates something in someone's experience to draw the problem out?
So you say you're having a problem with that version of the patch that you sent in the bug tracker, and not with any other version that might, for example, use "set open $1" in combination with folder names that contain spaces, or other problematic characters (such as commas, semicolons, etc) ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
chris clepper -
Hans-Christoph Steiner -
Mathieu Bouchard -
sonia yuditskaya