From CSWiki
Revision as of 02:48, 6 January 2008 by Gewang (talk | contribs)

Jump to: navigation, search

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

  • and 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,
  • CTRL + x is bound to "open file" while it refers to "cut selected text" in all other editors. This is confusing. fixed in CVS,
  • 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)

back to miniAudicle