Hey guys,
Images have been attached and connected to buttons, so at the moment whenever the 'q' key is pressed, acoustic.mp3 will start playing, and acoustic.png will show up on screen. The current issue is that for some strange (and very annoying) reason, the png decides to hide behind the background after flashing on screen. At first I thought this was a compatibility issue with png formats, however other programmers have used PImage tags with png's successfully.
Going to keep mulling over it for now, hopefully we find a solution soon. Worst case scenario (ideally avoided), is having a semi-opaque background, so instruments will still show from behind it.
v5.01 coming soon (removing images on stop playing)
Something else on my todo list for today: Expect a v5.01 out with image removal. It is apparently not that simple to get rid of the image, will probably get the buffer to clear its contents once a stop key is pressed, in which case we would have to move the buffer loading process from setup() to individual start playing keys. (i.e. Image loads in real time..this may make program startup slightly faster)
Fiducials
Once we migrate our system to fiducials, Maria's idea (which is really good), is to get the instruments to move around the screen according to the physical location of the related fiducial.
There is definitely a way of doing this, and I have a feeling we will find this way by going through the maths example that has been made available to the class.
For the time being however, instruments have pre-determined x and y points, reason being, we need the instruments to at least show up at this stage, to know that the code is working.
Good news, img.resize(0, 50); has just saved the day..
ReplyDeleteonce a stop play key is pressed, we can resize the current instance of the image to (0,0). when the same image is prompted to show on screen, a new instance of the image should be loaded from the buffer.
guys I'm done for now, gonna get ready for rugby and take out some serious Processing induced frustration lol..
ReplyDeletehttps://www.dropbox.com/home/Novel%20Grp%20D?select=mplayerv5,02.txt#:::36116562
uploaded what I've managed so far on Dropbox.
as it stands images will appear when the play button is pressed, and disappear once their stop button is pressed, the issue is that if we get an object to play, then get a second object to play, the image of the original object disappears.
I'm thinking that a repeat until (key == 'a') loop should work
need to figure out how to make it work with processing. Tried a do while, but that caused the song to not wanna stop when the stop button was pressed (which is odd since song method and image method are now separated completely)
Take a look at the code to understand what I'm talking about, images get called and stopped in the draw() method..audio gets called/stopped in the keypressed() method.
Hopefully this is an dumb error from my part as oppose to program limitation. Will have a second look when I'm back from training =)
Hi Kev,
ReplyDeleteI've analysed the problematic piece of code, and it seems that the problem is originating from the 'key' variable. This is because every time you press another key, the key variable is replaced to another value and the screen is redrawn together with the new image...
I'm trying to figure out a way to store different key values until the respective "remove picture key" is pressed... Still working on it, but I hope to arrive to a solution soon..
Keep me updated Ry, was trying to play around with repeat until and do while loops yesterday, processing didnt like the repeat until conditions, and made a mess of the do whiles =/
ReplyDeleteA worst case scenario would be switching from minim to sonia to see if the isPlaying() condition would be any good
do
{
Image.acousticImg(x,y);
}
while acoustic.isPlaying();
but that would mean a massive overhaul to most of our existing code (volume control, sound playback and recording would all require alterations (which may cause other bugs in the system)
I'll wait till this evening, if I hear no news I'll make a copy of the code and migrate to sonia.
ps. if you have skype feel free to add me, may make bug spotting/solving easier : rusty.boot is the name ;)
I'm still working on it and I'm planning to work more on it this evening as I'm still at work.. Will keep you updated Kev ;)
ReplyDeleteHey Kev,
ReplyDeleteManaged to formulate an algorithm which will hopefully solve the problem. I will transform it into code later today... For this algorithm some variables will initialise in setup() and the logic will be in draw().. Check it out::
In Setup()
char a = 'q';
char b = 'w';
key = 'X'
In Draw()
if (a == 'q') or (key == 'q') or (key == 'a') {
a = key;
if (a == 'q') or (b == 'q') or (key == 'q') {
draw image A;
b = a;
}
}
else if (a == 'a') {
a = 'q';
}
im not sure...but i think there's an infinite condition there..
ReplyDeleteyou're setting char a to always = q in setup,
so your line 1 in draw is gna be true (1 out of 3 or's), and key will always = a...
a is the key to stop playing the mp3 files and remove the image from UI.. =S
so result will be no play and no image =S
or did i miss something? =S
Hmm, does Setup() supposed to run only once? ie. at the start of the program? or am wrong?
ReplyDeleteI forgot to change variable b after key 'a' is pressed::
ReplyDeleteIn Draw() Updated
if (a == 'q') or (key == 'q') or (key == 'a') {
a = key;
if (a == 'q') or (b == 'q') or (key == 'q') {
draw image A;
b = a;
}
}
else if (a == 'a') {
a = 'q';
b = 'w';
}
you are correct Sir..setup runs prior to loading..in fact our buffers are all loading images/audio within setup() method.
ReplyDeleteDo you have any news about the fix? did it work as planned or should we start migrating from minim to sonia?
If im not mistaken, this issue is caused due to the keys.. i believe we won't have this issue when we start using the fiducials. we should try that out first and avoid a lot of hassle.
ReplyDeleteYes it worked perfectly except for a few minor changes to the algorithm... Check out the V6 link in the new post... :)
ReplyDelete