Author Topic: Show Programming  (Read 3836 times)

0 Members and 1 Guest are viewing this topic.

Agent C

  • Guest
Show Programming
« on: October 07, 2009, 11:56:53 pm »
I think I'm to the point where I want to release my code and give people the opportunity to start poking around with it.  Here's the deal though.  The only direction I plan on taking this is optimizing signal output, and maybe adding a few OpenGL based features (hidden line removal, contour tracing).  The info and preview windows may get a few tweaks.  Other than that, I don't want to do much else on the 'engine' side.  It will remain a low-level toy, intended to be used with midi instruments/triggers/controllers or a sequencing program like cubase.  Effects and clips and shows will have to be coded in by the user.  This will essentially be a laser graphics programming class for JAVA/Processing.

Would anybody be remotely interested in poking around with something that requires writing code to accomplish any sort of output?

Offline BlinkenLights

  • he's just this guy, ya know?
  • Administrator
  • Hero Member
  • *****
  • Posts: 726
  • Milliwatts: 4
  • Gender: Male
  • 'The Messenger' by Will Cascio
    • View Profile
Re: Show Programming
« Reply #1 on: October 08, 2009, 12:33:59 am »
hrm.. i would like to take a look at it and see.. im not a java coder, but i am good at fiddling

Offline James

  • Administrator
  • Hero Member
  • *****
  • Posts: 2089
  • Milliwatts: 46
  • Gender: Male
    • View Profile
    • LaserBoy !!!
Re: Show Programming
« Reply #2 on: October 08, 2009, 02:19:08 am »
Gee! That sounds very familiar!

For quite a while, LaserBoy was a bunch of code that I had to open in a compiler, write new frame generators or effects, compile and run. A loop for reading keystrokes to associate to those functions came later.

My suggestion would be to describe exactly what you are doing and what you have been able to accomplish with your ideas. From what I saw, you should be able to get some attention. I particularly like your use of midi to be able to associate live laser actions to a wide variety of control devices and your use of OpenGL and the GPU for vector computations. It might be just the core concepts that someone else has been waiting to build upon.

James.  :)
LaserBoy is Sofa King Cool!
But it will never be Alpha King Done!

Offline meandean

  • Sr. Member
  • ****
  • Posts: 466
  • Milliwatts: 13
  • It's about sight AND sound.
    • View Profile
Re: Show Programming
« Reply #3 on: October 08, 2009, 10:23:38 pm »
  I'm curious as to how you send data to the sound card!
"Patience is for the dead."

Offline James

  • Administrator
  • Hero Member
  • *****
  • Posts: 2089
  • Milliwatts: 46
  • Gender: Male
    • View Profile
    • LaserBoy !!!
Re: Show Programming
« Reply #4 on: October 09, 2009, 01:00:33 am »
Ooooooooh oh oh.... me too!  ;D

That is impossible with a Mac, ya' know.  %)

James.  :)
LaserBoy is Sofa King Cool!
But it will never be Alpha King Done!

Agent C

  • Guest
Re: Show Programming
« Reply #5 on: October 09, 2009, 02:41:24 pm »
The loop is really what I'm focusing on optimizing right now.  It is definitely a weak link.  The latest OpenGL has plenty of mechanisms for moving vector data in and out of the card with high efficiency.  Allow me to break it down

You can send one point at a time

You can send an array of points at a time - array vertexes

You can send the card a system memory location where the vertexes are stored and let the graphics card read from main memory.

You can compile vertex arrays and store them in the card memory which is DDR3 these days as vertex buffer objects which the card can then create instances of.  This part rocks, I don't use it yet but I will.  Now the graphics cards even have high level languages to do general operations on the card on the vertex data.

This is the fast step.  The vector calculations are performed on the card and returned in a feedback buffer object. 

Here is the slow step.
I must then step through the feedback buffer, taking the x,y,r,g,b for each point and insert that into a short[], after stepping through the entire returned buffer, I copy that short into a buffer that the sound API is continuously streaming from.  As geometry complexity increases, this parsing bogs down and gives the software less of an interactive feel.  The first optimization I plan to do is to break the parsing up into smaller chunks instead of the whole buffer at once to reduce waiting for the loop to finish.

It could be in the end that the transactional and GL overheard is so high that I would be better off doing all calculations in software...

I'll post things the way they are and then write an outline for the flow of the program.  Eventually I'll get around to adding some comments on the core.

 

SMF spam blocked by CleanTalk