Re: loading buffer w/ actionbutton

[James Harkins-2]

What exactly happens when the code stops working?

One potential problem with this code is that you start the readChannel and loadToFloatArray operations at the same time, but loadToFloatArray should not start until the readChannel is finished.

I think it should look more like this:

b = Buffer.readChannel(s, p, channels: 0, action: { |buf|

buf.loadToFloatArray( ..... );

});

Also -- please do not use the create.ucsb address anymore. That list is defunct -- the only reason it's still delivering messages is that there's nobody over there to shut it off. I'm moving the reply to the proper list.

hjh

On Jun 29, 2008, at 12:33 PM, Ali Bilgin Arslan wrote:

Hello,
I want to use something similar to the code below to use a dialog to load buffers (for more than one time). However, I noticed that it is not very versatile and may stop working after a few trials and the code refuses to work at that point.
Also, long files seem to take a really long time to load (it's probably because of the visualization, so it can be managed)
I have to use soundFileView to see the loaded buffer, so it has to stay.

Is there a more convenient way to do this ?

(   
ActionButton(w,"Load sample",{
    (
CocoaDialog.getPaths({ arg paths;
    paths.do({ arg p;    //you may need to erase b here first
        b = Buffer.readChannel(s, p, channels:0);
        b.loadToFloatArray(action: { arg array;
                        {
                            array = array.as(Array);
                        w = GUI.window.new(\test, Rect(10, 50, 600, 200)).front;
                        v = GUI.soundFileView.new(w, Rect(2, 2, 596, 196));
                        v.elasticMode = true;
                        v.data = array;
                        v.xZoom = array.size / 596;
                        v.refresh;
                        }.defer;
                        "done".postln;});
})},
        {"cancelled".postln}))
});   
)

: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman

[calvin harris]

has anyone else had problems with SCSoundFIleView crashing SC with
certain sndfiles? its weirdly unreproducable, but on some files it
does it all the time...
[ can post crash call stack if need be ]
 even copy+pasting + resaving ( in audacity ) would still crash it, but
applying an operation like amp normalize would make it save OK AFAIR

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[J. van Dijk]

I used SCSoundFileView in an application where it loaded around 15 soundfiles with a lengths from 4-15 minutes. I would crash on certain files, but it also crashed randomly while running the program and all the files where loaded. When I commented out the SCSoundFileView it wouldnt crash. 

Also I had less chance on a crash if I set the blocksize rather small:

scSoundFileView.readWithTask(block:16);

I couldn't locate the problem though and I don't know how to read crashlogs. This happened both on a G4 powerbook and a MacBookPro.

Gr,

Jorn 

On Jun 30, 2008, at 2:14 AM, calvin harris wrote:

has anyone else had problems with SCSoundFIleView crashing SC with
certain sndfiles? its weirdly unreproducable, but on some files it
does it all the time...
[ can post crash call stack if need be ]
even copy+pasting + resaving ( in audacity ) would still crash it, but
applying an operation like amp normalize would make it save OK AFAIR

_______________________________________________
sc-users mailing list


info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/