bad header info only on runtime462/OSX49


    Mar 18 2007 | 6:30 pm
    could somebody tell me why this patch doesn't work on my max462runtime on intel macbook pro os10.4.9 ?
    each time i record and automaticly play a file, i have a bad header info.
    however the file is well recorded.
    if i re-play it, it's ok...
    and it works perfectly on max457 / powerbook os10.3.9...
    why ?
    i become crazy.
    i surely made a mistake, but i can't find what.
    please.
    :~!
    f./

    • Mar 18 2007 | 6:35 pm
      here's the patch (upload file didn't work...):
      thx.
      f./
    • Mar 18 2007 | 6:57 pm
      I don't see what this user's problem has to do with this at all.
      Sounds like the patch loads and runs, but that there's a problem with
      the recorded audio.
      jb
      Am 18.03.2007 um 19:40 schrieb Mattijs Kneppers:
      >
      > have a look at this one:
      >
      > http://www.cycling74.com/forums/index.php?
      > t=msg&th=25059&start=0&rid=3579&S=dd2c619aab58cc0c59e57cab974f81f7
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Interactive audiovisual sampling soft- and hardware
      >
    • Mar 18 2007 | 7:32 pm
      yes, i don't think it's a os1049 problem.
      max launch fine with the combo update.
      please try the patch and tell me.
    • Mar 18 2007 | 8:58 pm
      On 18 mars 07, at 20:32, fp wrote:
      > please try the patch and tell me.
      no problem so far on a MacBook pro. What's really wrong for you? What
      are the steps to reproduce your problem?
      ej
    • Mar 18 2007 | 9:26 pm
      Quote: Emmanuel Jourdan wrote on Sun, 18 March 2007 21:58
      ----------------------------------------------------
      What's really wrong for you?
      What are the steps to reproduce your problem?
      >
      > ej
      >
      ----------------------------------------------------
      the steps are very simple.
      open the patch, put on adc, record few seconds and sop the recording.
      you'll have a bad header info message.
      i just find a way to avoid it, insert a [t b s] -> [del 10] (for bang) -> [zl reg], just before sending to buffer.
      and it works.
      is it my disk access to slow ? or something like that ?
    • Mar 18 2007 | 9:30 pm
      in fact it's works better with 20, 25 ms delay before sending to buffer.
    • Mar 18 2007 | 9:34 pm
      Quote: elt wrote on Sun, 18 March 2007 20:32
      ----------------------------------------------------
      > yes, i don't think it's a os1049 problem.
      > max launch fine with the combo update.
      >
      > please try the patch and tell me.
      >
      ----------------------------------------------------
      Ah, sorry. When there is a call to avoid an update I usually stay far away from it, which perhaps explains my premature reaction.
      I looked at your patch but I don't understand what to press. Could you include some steps to reproduce? I also miss ej.led.js.
      Cheers,
      Mattijs
    • Mar 18 2007 | 9:37 pm
      Quote: elt wrote on Sun, 18 March 2007 22:26
      ----------------------------------------------------
      > the steps are very simple.
      > open the patch, put on adc, record few seconds and sop the recording.
      > you'll have a bad header info message.
      >
      > i just find a way to avoid it, insert a [t b s] -> [del 10] (for bang) -> [zl reg], just before sending to buffer.
      > and it works.
      > is it my disk access to slow ? or something like that ?
      >
      ----------------------------------------------------
      Oh, sorry, missed that one. But what should I press to start recording? Also I see #1 arguments in the pvar objects. Isn't this patch supposed to be used as an abstraction?
      - Mattijs
    • Mar 18 2007 | 9:50 pm
    • Mar 18 2007 | 10:29 pm
      yes it seems to be effectively a question of time.
      with some [pipe] and [del] i can solve it.
      but i'll study your solution, just to learn more.
      :-)
    • Mar 19 2007 | 2:04 pm
      ok, thx a lot.
      it works perfectly now.
    • Mar 20 2007 | 10:51 pm
      it worked perfectly.
      in fact i have to insert delays to have it working properly.
      path to filewatch -> 50ms - 1 to filewatch -> 50 ms end of recording.
      otherwise it doesn't work at each time.
      it's empirical way.
      i don't really understand how work filewatch.
      could you please tell me what is wrong in my patch ?
      the filewatch process is in the subpatch "record".
      thx.
      f./
    • Mar 20 2007 | 11:25 pm