I´m working on a platform to teach how to read/write sheet music.
So far, It´s been "easy"* to figure out a system in which people select the minimal rhytmic units to WRITE some music, but I dont know even how to start to other direction of this process: how to create an input system to provide activities in which students could READ and tap some rhytms on the keyboard. Of course, my objective is to capture the time interval between taps in relation to beats. In other words....how to measure the time between taps.
I know softwares like EarMaster or GNUSolfege figured this out.
Any help would be much appreciated.
Thanks people :)
*"easy" because I´m a pianist/psychologist. All the PHP and JQuery and MySQL recently added to my life are still some hard/exciting things to understand.
Say you have a button. That button will have some method that runs when you tap it. What you will want to do is get the current time, it will depend on your language/platform but there is typically some built-in method. This will be in Unix time, which is the number of seconds that have elapsed since jan 1 1970 (or milliseconds). So each time a user taps the button, get that time (an integer of milliseconds) and store it / match it against the tempo.
This sounds easier if you have a pre-defined tempo. Just convert beats-per-minute into milliseconds-per-beat, and you would have a repeating timer in the app that plays a sound or flashes a color after that many milliseconds.
This is probably an unsatisfying answer, and generally, stack overflow should be used for questions that specifically relate to code. So when you know what language you are using and you start to implement this feature, if you run into problems, try asking this question again with your code / a minimal version of it and you will likely get a better answer.
I'm just currently writing my various routines. What I am doing is at every routine that say needs blending, I enable blending at the beginning and disable it at the end. Is this a bad thing?
For example:
Public Sub DrawQuad()
GL.Enable(EnableCap.Blend)
GL.BlendFunc(BlendingFactorSrc.SrcAlpha, BlendingFactorDest.OneMinusSrcAlpha)
GL.Begin()
GL.End()
GL.Disable(EnableCap.Blend)
End Sub
I have this, but I might call this 500 times in the same go, which means blending will get enabled/disabled 500 times. Will this greatly effect performance compared to just enabling once, drawing 500 quads and than disabling?
Premature optimization is the root of all evil!
As bcrist pointed out in the comments, if you're looking to optimize your OpenGL code, do learn the programmable pipeline. It's faster, more customizable, less reliant on magical function calls, and generally more awesome.
In general, optimize your big problems first, then get specific.
The best way to find out the answer to your question is to profile your code. OpenGL drivers are implemented by the hardware vendors for each device. Yes, calling any function repeatedly when you could call it just once will cause a performance hit, but how does that stack up against the rest of your code?
The take home point is admittedly annoying - your question is misguided and the "answer" isn't going to answer your actual question about calls to glEnable. You should optimize many things before you start looking at small functions like that.
For example, once you get the rest of your design sorted out and you realize that grouping together certain drawing routines by glEnable is even possible in your program, much less doable without incurring more overhead than it eliminates, then you might look into doing something to get rid of them.
I have been looking at the speed of my software trying to fine a line here and there that I can speed up. I do NOT need help with general optimisation. I have found a specific line of background unmanaged code that seems to be taking a very long time, even when the amount of calls are considered. This is the line:
system.windows.forms.unsafenativemethods.getwindowtext(handleRef hWnd, StringBuilder lpstring, int nMaxCount)
Does anyone know:
how to speed it up/bypass it if it's not useful/replace it with
something better.
specifically where I would have written something in my code that causes this to be called - the more example the better on this one!
I've found some related topics on Google. But each of these relate to
a specific issue such as an error occurring when a one thread asks
another thread for something and the other thread has become detached.
This Link is helpful, but I can't quiet get my head around it.
Any and all help will be appreciated.
Thanks!
It sounds like you're using Control.Text a lot - this seems like the most likely caller of GetWindowText.
If you're updating your UI with the results of your simulation every time the simulation makes progress, you may well be able to improve the performance significantly just by rate-limiting the updates (e.g. just update 5 times per second).
I have a problem. Animations (switching between viewControllers, scrolling tableView) on device are working with spurts but on simulator work fine. How to solve this problem?
I'm afraid there is no easy answer.
The only solution is to improve your code and make it lighter and more efficient.
I ran into such problems too and I had no other option but to make my module work better.
The first suggestion would be to check for memory leaks (this one helped me: http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/ ). Fixing the leaks should give a little more memory to work with.
If you have this spurts on the first gen ipad... meh, it's so and so. but if you have them on the ipad2, then you really need to rewrite your code: use less elements, make less operations, maybe use some background operations to perform some threads so you can leave the main thread free to make the animations
Scrolling tableViews shouldn't be too big a problem since it has been quite efficiently designed. Did you implement the method heightForRowAtIndexPat: ? If so, and you have much data in your tableView, it gets extremely slow. In that case better use a fixed height or the table.
In other words, do you spend time anticipating errors and writing code to get around these potential issues, or do you write the code as you see fit and then work through any errors on an issue by issue basis?
I've been thinking a lot about this lately and I'm very much a reactive person. I write my code, give it a whirl, go back correct error and repeat until application works as expected. However a friend of mine offered that he spends time thinking how each line is interpreted and fixes errors before they occur.
I must point out that re-active is pure PRE-live. I definitely make sure my application is working before it goes live.
There should always be a balance.
Too many error checking is slow and leads to garbage code. Not enough error checking makes your program crash on edge cases which is not very good to discover after having it shipped.
So you decide how reliable some piece of code should be and implement error checking accordingly. Some test utility can be not very reliable - less error checking. A COM server meant to be used by a third party search service in deep background should be super reliable - much more error checking.
I think asking this in isolation is kinda weird, and very subjective, however there are obviously a bunch of techniques that permit you to do each. I tend to use these two:
Test-driven development (this would seem to be proactive)
Strong, static typing (reactive, but part of a tight iterative development cycle, as in, it's enforced by my ML compiler, and I compile a lot)
Very occasionally I swerve into the world of formal verification of programs. That's definitely "reactive", but if you think a little more up-front, it tends to make the verification easier.
I must also say that I value a lot of up-front thought in programming. The easiest way to avoid bugs is to not write them in the first place. Sometimes it's inevitable, but often a little more time spent thinking about the problem can lead to better-quality solutions, and then the rest can be taken care of using the kinds of automated methods I talked about above.
I usually ask myself a bunch of what-ifs when coding, like
The user clicks the button, what if they didn't select a date?
The user is typing in the search box, what if they try to type html in there?
My label text depends on a value from a shared drive, what if it's not mapped?
and so on. By doing this I've found that when the application does go live, there are a ton fewer errors and I can focus on fixing more obscure bugs instead of correcting conditions that should have been in place to begin with.
I live by a simple principle when considering error-handling: garbage in, garbage out. If you don't want any garbage (e.g. invalid input) messing up your software, you have to find all the points in your software where it can get in and handle it. Of course, the more complicated your software is, the harder it is to find every point of entry, but I feel that the more you do up front the less reactive you will need to be later on.
I advocate the proactive approach.
I try to write the code in that style which results in maintainable and reliable code
I use the defensive programming techniques to prevent stupid errors in code due to my loss of attention and similar
I design the database model according to the fortress principle, SQL code checking for results after each singular operation
I think of potential problems that can happen with that part of the code and I account for that. Not for every possibility but for major ones I can think of right now.
This usually results in software operating rather smoothly. At times it even surprises me but that was the intended goal, so here we are.
IMHO, the word "Error" (or its loose synonym "bug") itself means that it is a program behavior that was not foreseen.
I usually try to design with all possible scenarios in mind. Of course, it is usually not possible to think of all possible cases. But thinking through and allowing for as many scenarios as possible is usually better than just getting something working as soon as possible. This saves a lot of time and effort debugging and redesigning the code. I often sit down with pen and paper for even the smallest of programing tasks before actually typing any code into my editor.
As I said, this will not eliminate all errors. For me it pays off many times over in terms of time spent debugging. Another benefit is that it results in a more solid and maintainable design with fewer bugfixing hacks and special cases added on later. But in any case, you will have to do a lot of debugging after the code is done.
This does not apply when all you want is a mockup or rapid prototype. Also practical constraints such as deadlines often makes a thorough evaluation difficult or impossible.
What kind of programming? It's impossible to answer this in any general way. (It's like asking "do you wear a helmet when playing?" -- well, playing what?)
At work, I'm working on a database-backed website. The requirements are strict, and if I don't anticipate how users will screw it up, I'm going to get a call at some odd hour of the day to fix it.
At home, I'm working on a program ... I don't even know what it'll do yet. I can't deal with 'errors' because I don't know what 'an error' is in this context, because I don't know what correct behavior is going to be. The entire purpose of the program can and frequently does change on a timescale of minutes to hours, so even a couple minutes spent thinking about errors this early is a complete waste of time. (It's even worse than browsing SO, since error-handling adds lines of code.)
I guess the only general answer is "I do what makes sense in terms of saving time in the long term", which is, after all, the whole reason to use machines to do work for us.