Feature Request #521

Rails app issues

Added by Tim Place over 11 years ago. Updated over 8 years ago.

Status:ClosedStart date:2010-06-03
Priority:NormalDue date:
Assignee:Tim Place% Done:

0%

Category:-Spent time:-
Target version:-
Branch:

Description

MulticoreOnRails: It is now actually working! A lot of details follow:

There are some things about Rails I never knew before, and which are a major pain: namely that it is constantly reloading and re-initializing the app -- meaning that any instance variables in the controller are completely bogus from one call to the next, and so a Multicore chain gets rebuilt (usually incorrectly) * EVERY TIME ANY REQUEST COMES INTO THE CONTROLLER * (e.g. for every single tiny movement of the AJAX slider).

So we can get around this for the purposes of this example by using global variables instead. I don't like this solution, but we're stuck with it for now. In fact, with the default settings for the development environment, even this global code gets called upon every single action from the views!!! I was able to stop that behavior by tweaking some of the rails config files. Fortunately for me, I had been on the phone with Jesse Allison earlier tonight when he suggested that this development/reloading stuff could end up being a big problem for me!

There is still some more work to do get this Rails UI performing the way that it claims. At the moment it is really just an oscillator, not an AM processor. Things that need to happen to make the AM processor:

- we need to be able to connect to a second inlet on op≈
- the wavetable≈ object doesn't yet have a linearGain attr like it should
- yes, the gain slider has zipper noise -- there is already a FR for that in redmine

History

#1 Updated by Trond Lossius about 11 years ago

There are some things about Rails I never knew before, and which are a major pain: namely that it is constantly reloading and re-initializing the app -- meaning that any instance variables in the controller are completely bogus from one call to the next, and so a Multicore chain gets rebuilt (usually incorrectly) * EVERY TIME ANY REQUEST COMES INTO THE CONTROLLER * (e.g. for every single tiny movement of the AJAX slider).

Yes, this is correct, almost. In Deployment Passenger will create several parallel instances for multithreading purposes, so that several incoming requests can be dealt with in parallel. For large Rails deployment, instances might even be branched out over several servers, all multithreading.

So for normal Rails work, anything that has to be dealt with globally, will need to go in the database. Of course that might be a challenge when dealing with RT audio.

One of many interesting new features of HTML5 is that is supports a <ruby> tag. My guess is that this will enable running ruby scripts in the browser, but I haven't seen any documentation of it yet (and haven't looked for it yet either). HTML5 also provides possibility of maintaining a database locally at the browser client, so that database apps can run standalone/offline.

#2 Updated by Tom Stoll about 11 years ago

Unfortunately, the <ruby> tag seems to have nothing to do with Ruby...

http://www.w3schools.com/html5/tag_ruby.asp

It's there to support annotations for East Asian characters.

#3 Updated by Trond Lossius over 9 years ago

  • Tracker changed from Bug to Feature Request

As all of this is in its infancy, I'd like to move it to feature requests rather than bug. There are some serious design work to be done here before moving further with implementation.

#4 Updated by Trond Lossius over 8 years ago

  • Status changed from New to Closed

Moved to GitHub

Also available in: Atom PDF