Difference between revisions of "MiniAudicle/Bugs"

From CSWiki
Jump to: navigation, search
 
(22 intermediate revisions by 10 users not shown)
Line 2: Line 2:
  
 
== Mac OS X version BUGS ==
 
== Mac OS X version BUGS ==
 +
* urgent: [[MiniAudicle/Bugs/PLOrk|showstopper bugs for PLOrk spring 2008]]
  
  
 
== Linux version BUGS ==
 
== Linux version BUGS ==
 +
* when you try to close a file and there is more than one file open, there is a segfault. ['''fixed''']
 +
* ctrl-x doesn't work, should be better to use ctrl-o for "open file". ['''fixed''']
 +
* miniAudicle freezes when trying to start virtual machine while jack running even it was compiled with 'make linux-jack' but runs back when jack stops
  
 +
== Windows version BUGS ==
 +
* 0.1.3.6 and 0.1.3.7 at least have problems under Windows 2000 SP4. If you launch the miniAudicle, the app comes up, you can adjust some preferences under .7, but once you click on Start Virtual Machine, the app doesn't accept any keyboard or GUI input. (ChucK still seems to work as a command line app.)
  
== Windows version BUGS ==
+
* Process remains in memory after the main window is closed. Even if no shreds were run and VM was not started. If there were any running shreds they keep producing sound after the window is closed. '''fixed in CVS, 0.1.3.4'''
* Process remains in memory after the main window is closed. Even if no shreds were run and VM was not started. If there were any running shreds they keep producing sound after the window is closed.
+
 
 +
* CTRL + x is bound to "open file" while it refers to "cut selected text" in all other editors. This is confusing. '''fixed in CVS, 0.1.3.4'''
 +
 
 +
 
 +
 
 +
 
 +
== Cross platform BUGS ==
 +
 
 +
* Probably rather minor: I am not sure whether this is desired behavior or a bug.  There seems to be something wonky with the handling of debugging.  If I put the text "foo;" into the main window and try to add a shred, it does as expected and tells me that there is an undefined variable.  But if I were to do that with some text such as "foo 5;" or "foo 100;" it does something interesting.  For "foo 5;" it will say "line(1).char(5): parse error".  But if I hit "add shred" again, it will tell me "line(1).char(5): parse error", and each time I click "add shred" it will add 5 again to the character number.  So, it gives me a character number equal to the total number of characters I have tried to add as shreds.  It seems that, if the program says there is an error in the fortieth character on line 1, when there are only 5 characters, something isn't quite right.  I don't know whether this is a big problem, because it doesn't seem to have any wide consequences.  It only happens if the text is on line one.  It does seem to add it up over a session though. If I put some legitimate code on previous lines, for example putting "SinOsc s => dac;" on line one, with something like "foo 5;" on line 2, and then try to add it a few times, and then delete line 1, and try to add just "foo 5;", the character number it gives me is equal to the sum total of characters that I have tried to add as shreds.  Well, it's a pretty trivial-sounding bug, and probably not important, but I thought I would attempt to explain it as fully as possible in case it actually is a problem.
 +
::This is actually a cross-platform bug, it also manifests under Linux and Windows and it's quite annoying as the moment when you already tried to compile the same code a few times is likely the same moment when you could very much use knowledge of the exact character at which the error occurs. It's a known issue (at least it was reported), I'm not quite sure why it wasn't on this page yet. Should we perhaps make a new "cross platform bugs" section? It would be good if it would be clear that not only are ChucK and the Mini cross-platform, many bugs are as well, a great victory for the concept of community-building through bug-hunting if ever there was one! (Kas).
 +
 
 +
* the terminal keyboard seem unable to send keystrokes to the VM. Perhaps highlighting the "console monitor" should asign the keyboard to the VM? (Kas.)
 +
** Good Idea.  Currently you can send keyboard input to the VM by running miniAudicle from the command line, but clearly an integrated solution is more desirable (HidIn keyboard input still works without the command line, though) (Spencer)
 +
***Ok, but it would seem that it would be a rare senario in which you'd like to use the same keyboard for both typing code and controling music ''at the same time''. I vote for using the comand window since that one currently doesn't accept keyboard input itself and it would be functionally similar to chucking with two comand prompt windows. I'm on Windows so I haven't yet seen the more elaborate graphical elements. Perhaps in order to combine the keyboard with graphical controlls in a fluent way we could have a switch that would toggle the keyboard between normal (editing) use and sending it to the VM? I'd like to avoid the situation where moving a slider highlights the graphical interface window and so as a side effect makes the keyboard lose touch with the VM. Defining your own musical keyboard functionality is very nice but only as long as you have the feeling you can depend on it. Maybe we could use "Scroll lock" as a toggle? That would be nice because that would make the keyboard itself indicate it's function, that could be a advantage in a performance situation. Just thinking out loud here. (Kas.)
 +
*** Yeah that makes sense.  My laptop actually doesnt even have a scroll lock key.  Maybe a really general solution would make sense: a button on the console monitor that activates sending keydowns to the VM, which can also be bound to a user-definable key (with optional modifier).  Once Windows/Linux has UI elements something like this actually could even be mostly implemented with available UI elements.  (Spencer)
 +
*** After more thought (and time) this is now only a issue when we can't use the HID version of the keyboard because we need keyboard control yet don't want ChucK to respond to keystrokes made while coding. Seems like a fairly rare situation though a solution in due time might still be worthwhile. (kas).
  
* CTRL + x is bound to "open file" while it refers to "cut selected text" in all other editors. This is confusing. '''fixed in CVS'''
+
back to [[miniAudicle]]

Latest revision as of 13:21, 27 June 2008

Report all fishiness here:

Mac OS X version BUGS


Linux version BUGS

  • when you try to close a file and there is more than one file open, there is a segfault. [fixed]
  • ctrl-x doesn't work, should be better to use ctrl-o for "open file". [fixed]
  • miniAudicle freezes when trying to start virtual machine while jack running even it was compiled with 'make linux-jack' but runs back when jack stops

Windows version BUGS

  • 0.1.3.6 and 0.1.3.7 at least have problems under Windows 2000 SP4. If you launch the miniAudicle, the app comes up, you can adjust some preferences under .7, but once you click on Start Virtual Machine, the app doesn't accept any keyboard or GUI input. (ChucK still seems to work as a command line app.)
  • Process remains in memory after the main window is closed. Even if no shreds were run and VM was not started. If there were any running shreds they keep producing sound after the window is closed. fixed in CVS, 0.1.3.4
  • CTRL + x is bound to "open file" while it refers to "cut selected text" in all other editors. This is confusing. fixed in CVS, 0.1.3.4



Cross platform BUGS

  • Probably rather minor: I am not sure whether this is desired behavior or a bug. There seems to be something wonky with the handling of debugging. If I put the text "foo;" into the main window and try to add a shred, it does as expected and tells me that there is an undefined variable. But if I were to do that with some text such as "foo 5;" or "foo 100;" it does something interesting. For "foo 5;" it will say "line(1).char(5): parse error". But if I hit "add shred" again, it will tell me "line(1).char(5): parse error", and each time I click "add shred" it will add 5 again to the character number. So, it gives me a character number equal to the total number of characters I have tried to add as shreds. It seems that, if the program says there is an error in the fortieth character on line 1, when there are only 5 characters, something isn't quite right. I don't know whether this is a big problem, because it doesn't seem to have any wide consequences. It only happens if the text is on line one. It does seem to add it up over a session though. If I put some legitimate code on previous lines, for example putting "SinOsc s => dac;" on line one, with something like "foo 5;" on line 2, and then try to add it a few times, and then delete line 1, and try to add just "foo 5;", the character number it gives me is equal to the sum total of characters that I have tried to add as shreds. Well, it's a pretty trivial-sounding bug, and probably not important, but I thought I would attempt to explain it as fully as possible in case it actually is a problem.
This is actually a cross-platform bug, it also manifests under Linux and Windows and it's quite annoying as the moment when you already tried to compile the same code a few times is likely the same moment when you could very much use knowledge of the exact character at which the error occurs. It's a known issue (at least it was reported), I'm not quite sure why it wasn't on this page yet. Should we perhaps make a new "cross platform bugs" section? It would be good if it would be clear that not only are ChucK and the Mini cross-platform, many bugs are as well, a great victory for the concept of community-building through bug-hunting if ever there was one! (Kas).
  • the terminal keyboard seem unable to send keystrokes to the VM. Perhaps highlighting the "console monitor" should asign the keyboard to the VM? (Kas.)
    • Good Idea. Currently you can send keyboard input to the VM by running miniAudicle from the command line, but clearly an integrated solution is more desirable (HidIn keyboard input still works without the command line, though) (Spencer)
      • Ok, but it would seem that it would be a rare senario in which you'd like to use the same keyboard for both typing code and controling music at the same time. I vote for using the comand window since that one currently doesn't accept keyboard input itself and it would be functionally similar to chucking with two comand prompt windows. I'm on Windows so I haven't yet seen the more elaborate graphical elements. Perhaps in order to combine the keyboard with graphical controlls in a fluent way we could have a switch that would toggle the keyboard between normal (editing) use and sending it to the VM? I'd like to avoid the situation where moving a slider highlights the graphical interface window and so as a side effect makes the keyboard lose touch with the VM. Defining your own musical keyboard functionality is very nice but only as long as you have the feeling you can depend on it. Maybe we could use "Scroll lock" as a toggle? That would be nice because that would make the keyboard itself indicate it's function, that could be a advantage in a performance situation. Just thinking out loud here. (Kas.)
      • Yeah that makes sense. My laptop actually doesnt even have a scroll lock key. Maybe a really general solution would make sense: a button on the console monitor that activates sending keydowns to the VM, which can also be bound to a user-definable key (with optional modifier). Once Windows/Linux has UI elements something like this actually could even be mostly implemented with available UI elements. (Spencer)
      • After more thought (and time) this is now only a issue when we can't use the HID version of the keyboard because we need keyboard control yet don't want ChucK to respond to keystrokes made while coding. Seems like a fairly rare situation though a solution in due time might still be worthwhile. (kas).

back to miniAudicle