julien breval

I am working on a new track (piano & live electronics) that will be recorded "live" (actually, "in realtime") to six tracks using something similar to [sfrecord~ 6].

Is it useful to defragment the hard disk before ? I think it requires a defragmenting utility ...

Also, the computer is a laptop so the hard drive is 4700 rpm. Some people advised me to use a Firewire external hard drive (7200 rpm) ; considering that the Firewire bus transmits about 400 Mbits / sec, is it really a serious choice ?

PS. Viruses: there are a few viruses that can attack OS X. On Windows and Linux I use AVG free, but there is no OS X version. A question to Mac users: is it useful to install an antivirus software on OS X ? Which one ?

Also, the computer is a laptop so the hard drive is 4700 rpm. Some people advised me to use a Firewire external hard drive (7200 rpm) ; considering that the Firewire bus transmits about 400 Mbits / sec, is it really a serious choice ? 

PS. Viruses: there are a few viruses that can attack OS X. On Windows and Linux I use AVG free, but there is no OS X version. A question to Mac users: is it useful to install an antivirus software on OS X ? Which one ?


optimizing-maxmsp-based-recording-on-os-x

On 24 Jun 2007, at 19:15, julienbreval wrote:

> Also, the computer is a laptop so the hard drive is 4700 rpm. Some 

> people advised me to use a Firewire external hard drive (7200 

> rpm) ; considering that the Firewire bus transmits about 400 

> Mbits / sec, is it really a serious choice ?

It's not the Firewire bandwidth that's the issue, it's the access 

time of the disk. To be honest, I wouldn't expect any problems with 

modern laptop disks for that number of tracks (although you've not 

said what bit depth or sampling rate you're going to use), and I 

would only worry about fragmentation if the disk were getting full.

> Also, the computer is a laptop so the hard drive is 4700 rpm. Some  
> people advised me to use a Firewire external hard drive (7200  
> rpm) ; considering that the Firewire bus transmits about 400  
> Mbits / sec, is it really a serious choice ?

It's not the Firewire bandwidth that's the issue, it's the access  
time of the disk. To be honest, I wouldn't expect any problems with  
modern laptop disks for that number of tracks (although you've not  
said what bit depth or sampling rate you're going to use), and I  
would only worry about fragmentation if the disk were getting full.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.loadbang.net


>Also, the computer is a laptop so the hard drive is 4700 rpm.

at some point i had problem recording (in msp)an 8 track file of one 

hour. As I remember there is a limit as to the size of the recorded 

file. I don't know if this is still aproblem, but 2 years ago 

recording 8x1hour with one sfrecord~ did not work

>
>
>Also, the computer is a laptop so the hard drive is 4700 rpm.

at some point i had problem recording (in msp)an 8 track file of one 
hour. As I remember there is a limit as to the size of the recorded 
file. I don't know if this is still  aproblem, but 2 years ago 
recording 8x1hour with one sfrecord~ did not work

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

Quote: Kasper T Toeplitz wrote on Mon, 25 June 2007 16:46

----------------------------------------------------

> at some point i had problem recording (in msp)an 8 track file of one 

> hour. As I remember there is a limit as to the size of the recorded 

> file. I don't know if this is still aproblem, but 2 years ago 

> recording 8x1hour with one sfrecord~ did not work

anyway I will do a complete recording test (at home) before going to the "official" studio

Quote: Kasper T Toeplitz wrote on Mon, 25 June 2007 16:46
----------------------------------------------------
> at some point i had problem recording (in msp)an 8 track file of one 
> hour. As I remember there is a limit as to the size of the recorded 
> file. I don't know if this is still  aproblem, but 2 years ago 
> recording 8x1hour with one sfrecord~ did not work
----------------------------------------------------
it's ok since my track is 30 min long

anyway I will do a complete recording test (at home) before going to the "official" studio


Quote: jeanfrancois.charles wrote on Mon, 25 June 2007 17:43

> You won't use the same computer for the live electronics and the recording,

of course I will ! (unless I find some problems with it while rehearsing) What is wrong with that ?

Quote: jeanfrancois.charles wrote on Mon, 25 June 2007 17:43
----------------------------------------------------
> You won't use the same computer for the live electronics and the recording,
> will you?
----------------------------------------------------
of course I will ! (unless I find some problems with it while rehearsing) What is wrong with that ?


Quote: jeanfrancois.charles wrote on Mon, 25 June 2007 23:14

> Well, in that case, check the CPU of your patch without recording and with.

> Maybe also using a sfplay~ and your 6-channel sfrecord~ would be bad for

> playback and/or recording (if your patch uses sfplay~, you might consider

> relocating to [buffer~] and [groove~] or something like that).

> In any case, you will see that while testing.

> Open the "Activity Monitor" (in Applications/Utilities) while you do your

> testing, to see the "real" CPU usage, as well as the disk usage.

That's more or less what I intended to do.

CPU itself shouldn't be a problem, but indeed I use some sfplay~ functions that could be replaced by a buffer~/groove~ combination (I will have to check the RAM though).

Quote: jeanfrancois.charles wrote on Mon, 25 June 2007 23:14
----------------------------------------------------
> Well, in that case, check the CPU of your patch without recording and with.
> Maybe also using a sfplay~ and your 6-channel sfrecord~ would be bad for
> playback and/or recording (if your patch uses sfplay~, you might consider
> relocating to [buffer~] and [groove~] or something like that).
>
> In any case, you will see that while testing.
> Open the "Activity Monitor" (in Applications/Utilities) while you do your
> testing, to see the "real" CPU usage, as well as the disk usage.
----------------------------------------------------
That's more or less what I intended to do.
CPU itself shouldn't be a problem, but indeed I use some sfplay~ functions that could be replaced by a buffer~/groove~ combination (I will have to check the RAM though).


Also, you might consider adjusting the disk buffer. My patches do a 

fair amount of heavy disk-reading and writing at the same time using 

sflist~ and a larger disk buffer and I haven't had a problem. (and in 

a patch that averages 50-60% and tops out at 80-85%) I will add the 

caveat that most of the soundfiles that I play are relatively short 

Also, you might consider adjusting the disk buffer.  My patches do a 
fair amount of heavy disk-reading and writing at the same time using 
sflist~ and a larger disk buffer and I haven't had a problem.  (and in 
a patch that averages 50-60% and tops out at 80-85%)  I will add the 
caveat that most of the soundfiles that I play are relatively short 
(2-20 seconds).

Don't worry about viruses - if you're concerned, you can download ClamX AV*,

a free, open source anti-virus app that's pretty good... at detecting

Windows-based viruses! I'd download it, NOT install it, and should you hear

about a new OS X virus in the wild (btw, there's none that I know of), then

install it. I'm a sysadmin who did install it on the Macs I look after over

a year ago, as there was news of a OS X virus in the wild... which never

amounted to anything, really (and I'm currently NOT using ClamX AV. For

*Most machines were able to run it with no CPU issues, but some of the

dual-core G5 workstations saw serious CPU spikes from the app, FYI

Regarding defragging, I bought iDefrag, used it to defrag both of my Macs

and... it didn't make any difference, performance-wise (except that I

couldn't use either computer for hours while they were being defragged!)

Your experience may be different, but I think you can save your cash and NOT

> Quote: jeanfrancois.charles wrote on Mon, 25 June 2007 23:14

> ----------------------------------------------------

> > Well, in that case, check the CPU of your patch without recording and

> > Maybe also using a sfplay~ and your 6-channel sfrecord~ would be bad for

> > playback and/or recording (if your patch uses sfplay~, you might

> > relocating to [buffer~] and [groove~] or something like that).

> > In any case, you will see that while testing.

> > Open the "Activity Monitor" (in Applications/Utilities) while you do

> > testing, to see the "real" CPU usage, as well as the disk usage.

> That's more or less what I intended to do.

> CPU itself shouldn't be a problem, but indeed I use some sfplay~ functions

> that could be replaced by a buffer~/groove~ combination (I will have to

http://www.flickr.com/photos/east_asia_photo_gallery/

http://picasaweb.google.com/maxmsp/KoreaKoreaKoReverendAlGreen

Don't worry about viruses - if you're concerned, you can download ClamX AV*,
a free, open source anti-virus app that's pretty good... at detecting
Windows-based viruses!  I'd download it, NOT install it, and should you hear
about a new OS X virus in the wild (btw, there's none that I know of), then
install it. I'm a sysadmin who did install it on the Macs I look after over
a year ago, as there was news of a OS X virus in the wild... which never
amounted to anything, really (and I'm currently NOT using ClamX AV.  For
now...)
*Most machines were able to run it with no CPU issues, but some of the
dual-core G5 workstations saw serious CPU spikes from the app, FYI

Regarding defragging, I bought iDefrag, used it to defrag both of my Macs
and... it didn't make any difference, performance-wise (except that I
couldn't use either computer for hours while they were being defragged!)

Your experience may be different, but I think you can save your cash and NOT
buy AV and defragging apps

On 6/26/07, julienbreval  wrote:
>
>
> Quote: jeanfrancois.charles wrote on Mon, 25 June 2007 23:14
> ----------------------------------------------------
> > Well, in that case, check the CPU of your patch without recording and
> with.
> > Maybe also using a sfplay~ and your 6-channel sfrecord~ would be bad for
> > playback and/or recording (if your patch uses sfplay~, you might
> consider
> > relocating to [buffer~] and [groove~] or something like that).
> >
> > In any case, you will see that while testing.
> > Open the "Activity Monitor" (in Applications/Utilities) while you do
> your
> > testing, to see the "real" CPU usage, as well as the disk usage.
> ----------------------------------------------------
> That's more or less what I intended to do.
> CPU itself shouldn't be a problem, but indeed I use some sfplay~ functions
> that could be replaced by a buffer~/groove~ combination (I will have to
> check the RAM though).
>
>

-- 
arliss renwick
http://www.myspace.com/radiopellucid
http://www.flickr.com/photos/east_asia_photo_gallery/
http://picasaweb.google.com/maxmsp/KoreaKoreaKoReverendAlGreen

Quote: peter.mcculloch@gmail.com wrote on Tue, 26 June 2007 01:21

> Also, you might consider adjusting the disk buffer. My patches do a 

> fair amount of heavy disk-reading and writing at the same time using 

> sflist~ and a larger disk buffer and I haven't had a problem. (and in 

> a patch that averages 50-60% and tops out at 80-85%) I will add the 

> caveat that most of the soundfiles that I play are relatively short 

That's a good idea. The problem is that I use sfplay~ for playing a few raw "long" files only (about 20 files). Besides this, lots of "short" files are played by a buffer~/groove~ polyphonic sampler that also adds some treatments (mostly filters and amplitude envelopes). 

After reflecting about this yesterday, for the studio version I may record without the long samples and add them later inside Digital Performer.

Quote: peter.mcculloch@gmail.com wrote on Tue, 26 June 2007 01:21
----------------------------------------------------
> Also, you might consider adjusting the disk buffer.  My patches do a 
> fair amount of heavy disk-reading and writing at the same time using 
> sflist~ and a larger disk buffer and I haven't had a problem.  (and in 
> a patch that averages 50-60% and tops out at 80-85%)  I will add the 
> caveat that most of the soundfiles that I play are relatively short 
> (2-20 seconds).
>
> Peter McCulloch
>
> www.petermcculloch.com
>
>
----------------------------------------------------

That's a good idea. The problem is that I use sfplay~ for playing a few raw "long" files only (about 20 files). Besides this, lots of "short" files are played by a buffer~/groove~ polyphonic sampler that also adds some treatments (mostly filters and amplitude envelopes). 
After reflecting about this yesterday, for the studio version I may record without the long samples and add them later inside Digital Performer.


Quote: Arliss Renwick wrote on Tue, 26 June 2007 01:34

> Don't worry about viruses - if you're concerned, you can download ClamX AV*,

> a free, open source anti-virus app that's pretty good... at detecting

> Windows-based viruses! I'd download it, NOT install it, and should you hear

> about a new OS X virus in the wild (btw, there's none that I know of), then

> install it. I'm a sysadmin who did install it on the Macs I look after over

> a year ago, as there was news of a OS X virus in the wild... which never

> amounted to anything, really (and I'm currently NOT using ClamX AV. For

> *Most machines were able to run it with no CPU issues, but some of the

> dual-core G5 workstations saw serious CPU spikes from the app, FYI

> Regarding defragging, I bought iDefrag, used it to defrag both of my Macs

> and... it didn't make any difference, performance-wise (except that I

> couldn't use either computer for hours while they were being defragged!)

> Your experience may be different, but I think you can save your cash and NOT

Thanks for this information Arliss. I never experienced fragmentation problems on this (new) machine but the hard drive has still lots of free space.

Quote: Arliss Renwick wrote on Tue, 26 June 2007 01:34
----------------------------------------------------
> Don't worry about viruses - if you're concerned, you can download ClamX AV*,
> a free, open source anti-virus app that's pretty good... at detecting
> Windows-based viruses!  I'd download it, NOT install it, and should you hear
> about a new OS X virus in the wild (btw, there's none that I know of), then
> install it. I'm a sysadmin who did install it on the Macs I look after over
> a year ago, as there was news of a OS X virus in the wild... which never
> amounted to anything, really (and I'm currently NOT using ClamX AV.  For
> now...)
> *Most machines were able to run it with no CPU issues, but some of the
> dual-core G5 workstations saw serious CPU spikes from the app, FYI
>
> Regarding defragging, I bought iDefrag, used it to defrag both of my Macs
> and... it didn't make any difference, performance-wise (except that I
> couldn't use either computer for hours while they were being defragged!)
>
> Your experience may be different, but I think you can save your cash and NOT
> buy AV and defragging apps
----------------------------------------------------

Thanks for this information Arliss. I never experienced fragmentation problems on this (new) machine but the hard drive has still lots of free space.


> file. I don't know if this is still aproblem, but 2 years ago recording 

> 8x1hour with one sfrecord~ did not work

Yeah, a 2 GB file size limit. If you record 8 tracks into a single file, 

this is reached roughly at about 50 minutes (16-bit/44.1 kHz)...

I believe HFS+ was introduced to circumvent this and other limitations, 

but programs might still inherit this behaviour....

Kasper T Toeplitz schrieb:
> at some point i had problem recording (in msp)an 8 track file of one 
> hour. As I remember there is a limit as to the size of the recorded 
> file. I don't know if this is still  aproblem, but 2 years ago recording 
> 8x1hour with one sfrecord~ did not work

Yeah, a 2 GB file size limit. If you record 8 tracks into a single file, 
this is reached roughly at about 50 minutes (16-bit/44.1 kHz)...

I believe HFS+ was introduced to circumvent this and other limitations, 
but programs might still inherit this behaviour....

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> Yeah, a 2 GB file size limit. If you record 8 tracks into a single 

> file, this is reached roughly at about 50 minutes (16-bit/44.1 kHz)...

If you run into this, you can always break up your files into multiple 

sfrecord~ objects. You can use click~ like the clapper that they use 

to synchronize film. (meaning, send a one-sample impulse to all the 

tracks at once after you start recording. Once you get it into Logic, 

DP, Protools, Cubase, etc., it's just a matter of matching up the 

> Yeah, a 2 GB file size limit. If you record 8 tracks into a single 
> file, this is reached roughly at about 50 minutes (16-bit/44.1 kHz)...
>

If you run into this, you can always break up your files into multiple 
sfrecord~ objects.  You can use click~ like the clapper that they use 
to synchronize film.  (meaning, send a one-sample impulse to all the 
tracks at once after you start recording.  Once you get it into Logic, 
DP, Protools, Cubase, etc., it's just a matter of matching up the 
sample in the different tracks.

>>Yeah, a 2 GB file size limit. If you record 8 tracks into a single 

>>file, this is reached roughly at about 50 minutes (16-bit/44.1 

>If you run into this, you can always break up your files into 

>multiple sfrecord~ objects. You can use click~ like the clapper 

>that they use to synchronize film. (meaning, send a one-sample 

>impulse to all the tracks at once after you start recording. Once 

>you get it into Logic, DP, Protools, Cubase, etc., it's just a 

>matter of matching up the sample in the different tracks.

but when i was recording this piece (live) i didn't knew about it 

(the inability of msp to record past this limit)

anyhow, i guess that's what all the protools, DP, etc etc are made for....

>>Yeah, a 2 GB file size limit. If you record 8 tracks into a single 
>>file, this is reached roughly at about 50 minutes (16-bit/44.1 
>>kHz)...
>>
>
>If you run into this, you can always break up your files into 
>multiple sfrecord~ objects.  You can use click~ like the clapper 
>that they use to synchronize film.  (meaning, send a one-sample 
>impulse to all the tracks at once after you start recording.  Once 
>you get it into Logic, DP, Protools, Cubase, etc., it's just a 
>matter of matching up the sample in the different tracks.

but when i was recording this piece (live) i didn't knew about it 
(the inability of msp to record past this limit)

On 26 Jun 2007, at 14:06, Stefan Tiedje wrote:

> As far as I know, in the beginning of this year, there arrived the 

> very first! and only! virus on the Mac.

Not true. I was removing viruses from Mac Plusses and SE's nearly 20 

> As far as I know, in the beginning of this year, there arrived the  
> very first! and only! virus on the Mac.

Not true. I was removing viruses from Mac Plusses and SE's nearly 20  
years ago. (WDEF anyone?)

optimizing Max/MSP-based recording on OS X