search

monome / aleph

open source sound computer
Other
80 stars 39 forks source link

freeze on metro deletion #177

Closed SorenAndreasen closed 10 years ago

SorenAndreasen commented 10 years ago

bees 0.4.3 loaded module: waves when trying to delete a metro op --> freeze. hardboot requried

tehn commented 10 years ago

can you provide more details on this? ie, clean boot (key2) create op, delete op? what's the exact reproducible process?

On Thu, Feb 20, 2014 at 10:43 PM, SorenAndreasen notifications@github.comwrote:

bees 0.4.3 loaded module: waves when trying to delete a metro op --> freeze. hardboot requried

Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/177 .

SorenAndreasen commented 10 years ago

this is when a metro is active and has a period of 5ms while changing amp0 param. bees start running extremely slow and if i try to delete the metro opbject it almost stalls completely.

SorenAndreasen commented 10 years ago

yesterday it froze completely though. i don't know what i did different today i'm afraid

tehn commented 10 years ago

metro at 5ms is taxing the processor pretty hard. we should simply raise the minimum metro time. there's no real good reason to use a metro at 5ms.

On Fri, Feb 21, 2014 at 11:11 AM, SorenAndreasen notifications@github.comwrote:

yesterday it froze completely though. i don't know what i did different today i'm afraid

Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/177#issuecomment-35744965 .

tehn commented 10 years ago

it probably crashed yesterday because other stuff was happening at the same time and couldn't keep up.

On Fri, Feb 21, 2014 at 11:11 AM, SorenAndreasen notifications@github.comwrote:

yesterday it froze completely though. i don't know what i did different today i'm afraid

Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/177#issuecomment-35744965 .

catfact commented 10 years ago

can't reproduce with 0.4.3 (release build). my steps:

other steps i should be taking?

in general: 5ms metro (indeed, 1ms) shouldn't be a problem per se. what will overtax the avr32 is other stuff that the metro can be triggering:

i actually think a fast metro is very useful for making arbitrary LFOs and so on; in the above example it woud be nice if it went down to 1ms so you can use smaller steps and prevent some aliasing. raising the lower limit seems like the wrong answer since you can always build a network that tries to do too much; the user just has to be aware of limitations. notice that i did raise the default metro period to 125ms, to encourage "musical-time" applications by default, instead of "dsp-time."

in any case, i don't think any of this is directly related to the crash. soren, are you aware that the DELETE command actually deletes the last operator created, not the operator selected necessarily? so maybe you deleted a different operator that caused the crash; something who's de-intialization hasn't been tested properly.

tehn commented 10 years ago

indeed, agreed, and good to hear more detailed info on this.

from my own experience with cpu overloads, i'm using a metro at perfectly reasonable rates (50ms up) with a heavy op like LIFE, but accidentally swing the encoder the wrong way to tune the metro period and boom done. so there are a few fragile situations, but obviously we can't do a whole lot about that. best not worry about this.

re: lowering to 1ms, my solution to aliasing has been to use slews, which are way rad

On Fri, Feb 21, 2014 at 1:30 PM, ezra buchla notifications@github.comwrote:

can't reproduce with 0.4.3 (release build). my steps:

  • clean boot
  • make metro -> accum -> hz0
  • set accum boundaries near the middle and metro period = 5ms.
  • enable metro.
  • with everything running, delete all the operators.

other steps i should be taking?

in general: 5ms metro (indeed, 1ms) shouldn't be a problem per se. what will overtax the avr32 is other stuff that the metro can be triggering:

-

screen redraws. i haven't had this crash the unit, but in the example above, there is a noticeable slowdown in play mode if you are actually display the hz0 changes. event queue is probably constantly full, which can't be good for stability.

expensive operators or lots of networks (e.g. LIFE)

serial messages in debug mode.

i actually think a fast metro is very useful for making arbitrary LFOs and so on; in the above example it woud be nice if it went down to 1ms so you can use smaller steps and prevent some aliasing. raising the lower limit seems like the wrong answer since you can always build a network that tries to do too much. notice that i did raise the default metro period to 125ms, to encourage "musical-time" applications by default, instead of "dsp-time."

in any case, i don't think any of this is directly related to the crash. soren, are you aware that the DELETE command actually deletes the last operator created, not the operator selected necessarily? so maybe you deleted a different operator that caused the crash; something who's de-intialization hasn't been tested properly.

Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/177#issuecomment-35758733 .

catfact commented 10 years ago

actually i agree that 5ms is quite sufficient... it is cool that the thing can allow you pretty low-level control of audio right from bees; slew time can be tuned to <1ms, you can make an interpolated waveform of ops if you want.... but, this is a very different kind of use! the source code can be tuned easily enough, either by making a personal fork (bees-dsp! whatever) or by implementing configuration files (issue #151)

in that light it seems totally fine to bump the min up if it is causing problems regularly? and generally apply that principle to such questions.

better yet, think of ways to make the network more chokeproof in general, and of speeding up heavy ops!

On 02/21/2014 12:42 PM, brian crabtree wrote:

indeed, agreed, and good to hear more detailed info on this.

from my own experience with cpu overloads, i'm using a metro at perfectly reasonable rates (50ms up) with a heavy op like LIFE, but accidentally swing the encoder the wrong way to tune the metro period and boom done. so there are a few fragile situations, but obviously we can't do a whole lot about that. best not worry about this.

re: lowering to 1ms, my solution to aliasing has been to use slews, which are way rad

On Fri, Feb 21, 2014 at 1:30 PM, ezra buchla notifications@github.comwrote:

can't reproduce with 0.4.3 (release build). my steps:

  • clean boot
  • make metro -> accum -> hz0
  • set accum boundaries near the middle and metro period = 5ms.
  • enable metro.
  • with everything running, delete all the operators.

other steps i should be taking?

in general: 5ms metro (indeed, 1ms) shouldn't be a problem per se. what will overtax the avr32 is other stuff that the metro can be triggering:

screen redraws. i haven't had this crash the unit, but in the example above, there is a noticeable slowdown in play mode if you are actually display the hz0 changes. event queue is probably constantly full, which

can't be good for stability.

expensive operators or lots of networks (e.g. LIFE)

serial messages in debug mode.

i actually think a fast metro is very useful for making arbitrary LFOs and so on; in the above example it woud be nice if it went down to 1ms so you can use smaller steps and prevent some aliasing. raising the lower limit seems like the wrong answer since you can always build a network that tries to do too much. notice that i did raise the default metro period to 125ms, to encourage "musical-time" applications by default, instead of "dsp-time."

in any case, i don't think any of this is directly related to the crash. soren, are you aware that the DELETE command actually deletes the last operator created, not the operator selected necessarily? so maybe you deleted a different operator that caused the crash; something who's de-intialization hasn't been tested properly.

Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/177#issuecomment-35758733 .

— Reply to this email directly or view it on GitHub https://github.com/tehn/aleph/issues/177#issuecomment-35771374.

catfact commented 10 years ago

last thought, sorry:

the biggest problem with this is not even so much that it's possible to hang the network with too much stuff (it will always be possible) but that the "hanged" behavior looks like a hard crash, makes you lose your work and even necessitates a hard reboot.

it comes back yet again to the issue of using the watchdog NMI to break out of loops and stalls (issue #175). continuing relevant comments on that page...

On 02/21/2014 12:42 PM, brian crabtree wrote:

indeed, agreed, and good to hear more detailed info on this.

from my own experience with cpu overloads, i'm using a metro at perfectly reasonable rates (50ms up) with a heavy op like LIFE, but accidentally swing the encoder the wrong way to tune the metro period and boom done. so there are a few fragile situations, but obviously we can't do a whole lot about that. best not worry about this.

re: lowering to 1ms, my solution to aliasing has been to use slews, which are way rad

On Fri, Feb 21, 2014 at 1:30 PM, ezra buchla notifications@github.comwrote:

can't reproduce with 0.4.3 (release build). my steps:

  • clean boot
  • make metro -> accum -> hz0
  • set accum boundaries near the middle and metro period = 5ms.
  • enable metro.
  • with everything running, delete all the operators.

other steps i should be taking?

in general: 5ms metro (indeed, 1ms) shouldn't be a problem per se. what will overtax the avr32 is other stuff that the metro can be triggering:

screen redraws. i haven't had this crash the unit, but in the example above, there is a noticeable slowdown in play mode if you are actually display the hz0 changes. event queue is probably constantly full, which

can't be good for stability.

expensive operators or lots of networks (e.g. LIFE)

serial messages in debug mode.

i actually think a fast metro is very useful for making arbitrary LFOs and so on; in the above example it woud be nice if it went down to 1ms so you can use smaller steps and prevent some aliasing. raising the lower limit seems like the wrong answer since you can always build a network that tries to do too much. notice that i did raise the default metro period to 125ms, to encourage "musical-time" applications by default, instead of "dsp-time."

in any case, i don't think any of this is directly related to the crash. soren, are you aware that the DELETE command actually deletes the last operator created, not the operator selected necessarily? so maybe you deleted a different operator that caused the crash; something who's de-intialization hasn't been tested properly.

Reply to this email directly or view it on GitHubhttps://github.com/tehn/aleph/issues/177#issuecomment-35758733 .

— Reply to this email directly or view it on GitHub https://github.com/tehn/aleph/issues/177#issuecomment-35771374.

tehn commented 10 years ago

i'm seeing (and getting reports) of crashes when scene switching. particularly, switching away from 'this' scene which uses a metro. i take it this is a deinit issue.

tehn commented 10 years ago

sorry, sloppy assumptions, will test more thoroughly. the monome grid op could be suspect as well.

catfact commented 10 years ago

there is something bugged with timer removal. this affects polled operators and DELAY, and is better described in issue #178 . a sensible step would be rewriting the timer list to be double-linked for cleaner search maybe, as well as implementing the NMI as i've mentioned a few times here and there

catfact commented 10 years ago

seem to be fixed in aeaa73a5d491bede06c3f7a0a04498e9477cd147 , but keep an eye out