florian1947

I'm working on a patch which has several instances of a bpatcher, each using individual buffer~and groove~objects, and also a javascript.

The javascript is examining the buffer and yields a list of voiced regions.

I'm using the #0-mechanism for naming of individual buffer~ and groove~objects, and also as an attribute of the javascript, like: "js voicedetect #0".

will always post 0, although the buffer does contain audio data.

I suspect the problem lies in naming the buffer, but cannot understand why.

Hello
I'm working on a patch which has several instances of a bpatcher, each using individual buffer~and groove~objects, and also a javascript.
The javascript is examining the buffer and yields a list of voiced regions.
I'm using the #0-mechanism for naming of individual buffer~ and groove~objects,  and also as an attribute of the javascript, like: "js voicedetect #0".
All this is working. Then I use
if (jsarguments.length > 1)
	newName = jsarguments[0];
//newName has the correct value !
var foo = new Buffer(newName);

And this just doesn't work.  The line
var length = foo.length();
post(length);
will always post 0, although the buffer does contain audio data.
I suspect the problem lies in naming the buffer, but cannot understand why.
Any help would be much appreciated.
Thank you

javascript-inside-bpatcher

 set a buffer name to be just an integer. In your case the 

 to just the #0 which is an just a 4 digit integer.

You could try naming your buffer something like "#0_buffer", and in the JavaScript would be 

var newName = jsarguments[0] + "_buffer";

I think, that if you  can't set a buffer name to be just an integer. In your case the var newName = jsarguments[0]; sets the newName to just the #0 which is an just a 4 digit integer.
You could try naming your buffer something like "#0_buffer", and in the JavaScript would be var newName = jsarguments[0] + "_buffer";

The name I use as argument (alsowith the buffer~and groove~ objects) is indeed "#0_buf".

This does arrive correctly in the js object: "post(newName);" is OK, something like "1234_buf " or so.

Still, it doesn't seem to connect to the buffer~ of the same name.

I wonder if "var foo = new Buffer(newName);" is the culprit.

Sorry, I mistyped in my post.
The name I use as argument (alsowith the buffer~and groove~ objects) is indeed "#0_buf".
This does arrive correctly in the js object: "post(newName);" is OK, something like "1234_buf " or so.
Still, it doesn't seem to connect to the buffer~ of the same name.
I wonder if "var foo = new Buffer(newName);" is the culprit. 

1st, to get the actual "1st" js argument, you must use the 

 will give the just the name of js file loaded. But if you say 

2nd, not sure if this would even be an issue to e honest, but if the js get initialized before the [buffer] is created?

Try having a function that gets the buffer in the js, that is triggered from a 

Well, two things come to mind,
1st, to get the actual "1st" js argument, you must use the jsarguments[1], as the jsargument[0] will give the just the name of js file loaded. But if you say "post(newName);" is ok, you should already use that. 

2nd, not sure if this would even be an issue to e honest, but if the js get initialized before the [buffer] is created?
Try having a function that gets the  buffer in the js, that is triggered from a loadbang -> deferlow.


Well, newName is always correct and identical to the buffer name as passed to the bpatcher. From the looks of it , this would seem to work. Except that it doesn't.

Inside the bpatcher, I have a umenu for selection of different source files. The fault persists after repeated selection - so it doesn't seem to depend on initialisation timing.

I had also been wondering about scope of js variables. If some variable is global: does it mean global within the bpatcher, or global across all loaded instances of bpatcher? Could be a culprit, all the bpatchers globals messing with each other.

Timing - not sure.
Inside the bpatcher, I have a umenu for selection of different source files. The fault persists after repeated selection - so it doesn't seem to depend on initialisation timing.

I had also been wondering about scope  of js variables. If some variable is global: does it mean global within the bpatcher, or global across all loaded instances of bpatcher? Could be a culprit, all the bpatchers globals messing with each other.


javascript inside bpatcher