Lace
Reaction score
0

Profile posts Postings Media Albums About

  • I honestly like Sonny 2 better. The improved AI and the ability to make a partner defencive on a dime is spot on. But Sonny 1 had more potential for a charecter. Back then you could possess fire, lightning, and ice all the such things. now it revolves around physical, poison, ice, and Shadow. But Sonny 2 has Critical healing and that helps a Ton. And your avatar looks nothing like Megaman X2.
    I guesss it helps if you have the libraries I mentioned in the comments on main.cpp

    I read your avatar as
    Matrix Math Extensions (!!)
    It's a Casual conversation with an interesting person. he understood what I said. Who gives a Damn? and I'm Slightly Southern so Spelling is only my priority on Paper.
    By the time I realized what had been done, it was beyond the point of no return.
    I had run out of time and bristol board to do it over again.
    I feel like I explained that rather poorly; do you get it?

    I also timed this reply rather poorly (22 more seconds)
    Yaay!
    And so Napoleon Dynamite finally makes its way back to you after a few months vacation.

    And did you like the card? :debug:
    The prepareSources method would then be responsible for calling the inputs' prepare methods, and the recalculate method would pretty much be equivalent to the getValue method, but the VolatileDevice class enforces the recalculate method will only be called once between calls to prepare, even if getValue is called multiple times.
    Code:
    //A Device is considered a VolatileDevice if two consecutive calls of
    //the getValue function could return different values even if all source devices
    //return the same value on both calls of getValue
    abstract class VolatileDevice implements Device{
    	private boolean calculated=false;
    	private double calcValue;
    	public final void prepare(){calculated=false;prepareSources();}
    	protected abstract void prepareSources();
    	public final long getValue(){
    		if(!calculated) calcValue=recalculate();
    		calculated=true;
    		return calcValue;
    	}
    	protected abstract double recalculate();
    }
    A Device whose prepare method does more than call its inputs' prepare methods will extend the abstract class VolatileDevice.
    The prepare method also calls the prepare method on each of the Device's inputs (similar to the way getValue calls getValue on all the inputs).

    For many devices, this would be all the prepare method does, but for some it would have to do more.
    First thing we do is add a second method to the Device interface, like so:

    Code:
    interface Device{
    	public double getValue();
    	public void prepare();
    }
    Well you could do that too, but I have a more elegant solution which is more robust (i.e. if you decide you want to add another waveform, you can just add it without having to go back and change the number you divide by).

    And that solution is...
    Well, you could do it that way, and it would avoid the issue, while being negligibly less efficient. And, if you were having two entirely separate instruments, that would probably be the way to go. However, I was talking about having two different waveforms in the same instrument (a la ptvoice).
    Nope, the screwy bit is the fact that, since multiple devices are taking input from the oscillator, the oscillator's getValue() method gets called twice per sample frame, resulting in it cycling through its state twice as fast as it should. I'll share my solution whenever I go postcrazy again.

    And yes, you made an org called ick ickybtang etc. And I wouldn't call them godawful; maybe just, y'know... archangelawful xD
    There is a folder in this file with my name on it.
    I was unaware I had made an orgy entitled ick ickybtang.
    Or in fact any of these.

    They sound godawful D:
    Well, the unusual feature of the block diagram is that it would no longer be a tree - there would be TWO devices taking input from the oscillator instead of just one (unless you had a separate oscillator for each waveform).

    I'll give you a hint: the way the Java program would fail is that the frequency of both waveforms would be twice what it should be (and the note would therefore sound an octave higher than expected).
    Yes, and, if you added the waveforms like that, then what unusual feature might a block diagram of the synthesizer have which would cause the corresponding Java program not to work (at least with the paradigm I described earlier)?
  • Loading…
  • Loading…
  • Loading…
  • Loading…
Back
Top