Open Discussion

  Forums : Open Discussion

Direct midi input

Author	Message
Anonymous	Post: Jan 9th 2009 at 8:28 AM   I like TuxGuitar because it is Open Source and feels more usable and well conceived than other similar application I have tried in the past. But I miss the possibility to input tracks using a MIDI guitar. So I was thinking about writing a plugin to do that. Before spending my time, I would like to know if anyone else is working on this subject and if the developers of TuxGuitar think it is feasible. I also read somewhere on this forum that the next version of TuxGuitar will be written in C++ and based on WxWidgets. Frankly, I do not consider this a brilliant idea, after two years spent developing a Java application of this quality. The decision is up to the TuxGuitar development team, of course. But again, since I'm not interested in learning WxWidgets, I would like to know the developers' opinion about this and the state of the TuxGuitar project in general. Thank you for sharing TuxGuitar! Amedeo
Back to Top
Julian	Post: Jan 9th 2009 at 10:02 AM   In General it is planned to do a plugin for Record MIDI. but we did nothing yet. The plan is to make a tool dialog with the options to record what you play, and then once you finish recording something process all you recorded (like if you were importing midi), and generate the new track The plan is not do it in real time, because it needs a lot of process. I mean, ofcourse you can play the song while you are recording, but you'll don't see your input notes on recording time. you'll see your new track, after stop recording. This is because a lot of things that make users need a big CPU. process MIDI input(recording or just importing a midi file) is not so easy. there are a lot of things to calculate to get the best "tick" and "duration" ( see human tempo VS machine tempo ). numbers are never exactly, arpegios sometimes are very hard. and a lot of things like that. So this methods may be big. To put notes on real time, you also will need update the layout every time you add a note, and ofcourse the play process that is already running.. those things may make all hard. So this is why it's not planned to add it on real time mode.
Back to Top
Amedeo	Post: Jan 9th 2009 at 10:32 AM   I understand the cost of updating the interface while recording and normalizing data. Maybe a careful use of threads... There are also such things as a metronome, MIDI controllable start, stop and pause commands to keep your hands free, etc. The main advantage I see in using a MIDI guitar is that it can produce an independent MIDI channel for each string, thus allowing a precise recording of what is played. Of course this does not necessarily needs a real time input plugin (altough this would be quite handy), it could be done by the MIDI import plugin. But at the moment it processes each MIDI channel as a separate track, and the tablatures it generates are most of the time incorrect. What about the C++ rewriting question?
Back to Top
Julian	Post: Jan 9th 2009 at 11:12 AM   > Maybe a careful use of threads... It is not about critical sections.. it's about CPU ussage. if you are recording a solo, playing very fast. you maybe are adding 16 notes in 1 second. or if you play chords faster, each chord may have 6 notes * up *down *up.. makes a lot of notes in a second. and to it, you need increment the methods that calculates each note tick and duration. when you add notes in tuxguitar, a measure buffer image is created (with other things inside ofcourse). if you are looking "multitrack" mode, and i think to record you will do because you will looking your new track, and other existent tracks. this buffer is created on all tracks. This issue may needs a big CPU ussage. and, you'll have 2 other threads using CPU too, Sequencer for play, and a listener for record. Not all people have the latest CPU.. there are people that runs tuxguitar with old machines yet. another important thing is the MIDI Out port selected. if you are running a external soft synth, that have loaded a "big soundfont", this synth also may uses a lot of CPU. So it's not a critical section for threads. lock | unlock is implemented on tuxguitar, and it will not be a problem. but yes it may be a problem, if any user need to buy new hardware to use the plugin. > it could be done by the MIDI import plugin not sure if would be great to use it. because it's more planned to read files (full songs) instead of 1 track What we need, are the functions that get notes "start" and "duration" values. maybe, splitting it on a different .jar file and using it as shared from both plugins. however, MIDI Importer, needs a lot of works yet.. its one of the most poor plugin of tuxguitar. and the code is not so clean as i'd like.. in other words, i have planned to rewrite this plugin from zero (only keep input/output stream classes) However don't worry at all for this now. this MIDI Record, may need some development steps. We are near to release a new version of tuxguitar, so i don't want to modify anything on "TuxGuitar" project now. But yes you can work on the new plugin, and later, on a next step we can move needed things to tuxguitar project (such as "MIDI Input" port selection on settings, and MIDI In ports provided by some midi plugins.) For now, you can make a "tool" plugin, ( see as example tuxguitar-converter plugin ) And, use Midi Input devices from Java Sound Api (it will be replaced on the future for player.getMidiIn() provided from tuxguitar ) Try just make the record on this dialog, and ofcourse when you click "record" button, tuxguitar must start "play" (here we may need for the future, a measure ticks before start playing too. something that is planned to add). And then the hard work, of convert all recorded on one or more tracks. Something important, is that you may need uses "UndoableTrackGeneric" or better if you have your custom undoable. Or, if you want skip undo action for now, don't remember call "TuxGuitar.instance().getUndoableManager().discardAllEdits();" This is because, if after add new tracks user clicks Undo, but this operation don't have undo.. previously undoables "don't have idea" about the new tracks existense.. so all may crash, or work bad. > What about the C++ rewriting question? Sorry i forgot reply on my previous post.. it's something that i'm not sure how to say in english.. ( missunderstood is the word ? ) One day i had the idea (only an idea) of make a "new" (not about finish java version) tuxguitar on C/C++, with a different name.. I commented this idea to a person, and by mistake he understood "i will do" it. and in 1 week, it was in some public forums :). The idea was a new project.. not this. talking what we can from this, but not all. the idea was keep java version development, and wxWidgets was think as something initial (behing a layer, to be able to change widgets library on a future) because it have a lot of java like methods/functions that may make the work faster. you know, after develop in java, make a thread, sockets, widgets, seems to be easy. but on C/C++ it's not easy find libraries for that "multiplatform". wxWidgets have a lot of classes for that, and using it causes that i need to create only some layers "application -> abstract layers -> wxWigets" and just make application issues. other wise, starting from zero i need to alot of more things. however, this "idea" have about 2 years.. and i never did nothing.
Back to Top
Julian	Post: Jan 9th 2009 at 11:14 AM   Something important that i forget to say.. use "svn" version for this. there are changes on the TGSong structure since 1.0
Back to Top
Amedeo	Post: Jan 9th 2009 at 12:17 PM   OK, thanks for the answers. I've down a checkout from the svn repository. I'm going to import all that into eclipse projects, build it and start familiarizing with TuxGuitar structure.
Back to Top
Julian	Post: Jan 9th 2009 at 12:50 PM   Maybe at begin you may become crazy making run plugins ( not from .jars ) inside eclipse. There are some ways to do that, What i often do is, on TuxGuitar project properties, "Java Build Path" -> "Source" tab. i use "Link Source" button. and select the /src folder for each plugin i want develop. Then, if you have plugins at share/plugins, the .class files compiled by eclipse when you click run will be loaded before .jar class, so all must run. but, if you don't have the .jar file you'll need to tell tuxguitar about your plugin. each plugin in tuxguitar, must have at classpath a file: META-INF/services/plugin_interface ( don't remember the name now, see at any jar for it ). and inside this file, you can write each class that "implements" this interface. So if you don't have .jar plugins, you will need create this META-INF folder at classpath and add the info.. Once you have that, you will be able to edit the plugin sources, and see the changes when you click run on eclipse (instead of need rebuild the jar each time) another thing, One of the changes of tuxguitar 1.0, was compatibility with JRE 1.4, and with "non" sun JREs. try please keep this compatibility where you can. on this initial version, i told about use "java sound api" for midi record.. so it will not be compatible with all JVM.. but on the future i'll add MIDI In support on tuxguitar, so plugin will not need java sound api there (tuxguitar-jsa will be who use it). In other words, use java sound api now, but think that on future you'll receibe "events" such as notifyNoteOn( int channel, int key, int velocity) instead of receive a javax.sound.midi.MidiEvent It's for 2 reasons.. 1, is that on GCJ, there was (not sure if it's fixed now) a bug with MetaMessage data (byte array that for any reason lose data after a clone) .. the second, is that MIDI In provider plugins, may be native. and if we use "MidiEvent" classes, we need to to: native values -> to midievent -> plugin will extract values to know the channel, note and velocity while we can direct do: Native values -> Plugin.
Back to Top
Amedeo	Post: Jan 10th 2009 at 9:43 AM   Hi Julian, I put togheter some Eclipse projects for TuxGuitar and the gtp, jsa, midi, pdf, ptb and tef plugins. It looks like all is pretty much working, but: 1) When starting TuxGuitar, I get the following messages: edit_voice_1.png: not found edit_voice_2.png: not found Maybe you forgot to add "edit_voice_1.png" and "edit_voice_2.png" to the lavender skin? 2) I also get the following: org.herac.tuxguitar.gui.system.plugins.TGPluginException: An error ocurred when trying to set plugin status at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(TGPluginManager.java:66) at org.herac.tuxguitar.gui.TuxGuitar.displayGUI(TuxGuitar.java:219) at org.herac.tuxguitar.gui.TGMain.main(TGMain.java:6) Caused by: java.lang.UnsatisfiedLinkError: no tuxguitar-alsa-jni in java.library.path at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at org.herac.tuxguitar.player.impl.midiport.alsa.MidiSystem.(Unknown Source) at org.herac.tuxguitar.player.impl.midiport.alsa.MidiPortProviderImpl.listPorts(Unknown Source) at org.herac.tuxguitar.player.base.MidiPlayer.addPortProvider(MidiPlayer.java:703) at org.herac.tuxguitar.gui.system.plugins.base.TGMidiPortProviderPlugin.addPlugin(TGMidiPortProviderPlugin.java:30) at org.herac.tuxguitar.gui.system.plugins.base.TGMidiPortProviderPlugin.setEnabled(TGMidiPortProviderPlugin.java:52) at org.herac.tuxguitar.gui.system.plugins.TGPluginManager.openPlugins(TGPluginManager.java:62) ... 2 more Since I'm using Windows, I didn't include the TuxGuitar-alsa plugin in my project. Should I? 3) I see that TuxGuitar and some plugins include some empty "bin" folders in their folders. I usually call this folders "_bin", then, setting a filter like "_*" in Tortoise, they become invisible. 4) Concerning the META-INF folders, wouldn't it be simpler if they permanently resided in the projects folders instead of being dinamically created by the ANT build scripts? Thanks
Back to Top
Julian	Post: Jan 10th 2009 at 2:48 PM   Hi, 1). icons don't exist yet. i just sent a mail this week to Sascha ( Lavender icon mantainer ) , telling about these new icons we will need. Where icons can't be loaded, as default you should see a white rectangle. (look near Undo | Redo buttons ) 2). No you shouldn't include it. on SVN there are some prebuilded plugins, but are not "dependencies". alsa plugin is there because i use GNU/Linux... So you don't must use it on a non GNU/Linux OS. there are some JNI Plugins, that are platform dependant. 3). This bin folder isn't needed.. it's used by eclipse to put the compiled classes. nothing else.. remove it if you don't like it. 4) I originally had the folders.. but don't exactly remember now why i did them dynamically.. However if you use a real folder and add it to classpath to use with eclipse, it may don't get good results. You can have a lot of results of same "resource". but, you "can't" get more than 1 result of same resource on same Classpath loader. It means that if you are using a folder ( like Share/ ) in classpath, and you have 2 META-INF/services/xxxx only 1 will be loaded, because it's same class loader.. you can see this, if you add "share" folder of tuxguitar-jsa to classpath. the language files will be of tuxguitar or tuxguitar-jsa. but not both. To develop the plugins, what i do is a only META-INF folder on TuxGuitar project, and there i add all plugins that i working on. Or, if i have the .jar file on share/plugins, the service class name is taked from Jar.. but the class is loaded from the bin folder (because it is loaded first than plugins jars)
Back to Top
Amedeo	Post: Jan 10th 2009 at 5:41 PM   Wait, I was misinterpreting what was going on! I didn't realize that the SVN checkout (that I was expecting to only contain sources) had .jar files for the plugins inside TuxGuitarshareplugins. This explains the ALSA exception I was getting. But now that I have removed them, I'm not able to convince TuxGuitar to load the plugins built by Eclipse. I have copied the META-INF folders for each plugin from the corresponding .jar to the plugin folder. But I don't understand how can I tell Eclipse to put them on the classpath so that TuxGuitar can load them at runtime. Could you please show me how to do that? Thanks
Back to Top
Julian	Post: Jan 10th 2009 at 5:54 PM   there are things here. * to add a folder to the classpath on eclipse, (e.g: share folder ) just right click to it, and select "Build path -> use as source folder" ) Now "share" is at classpath. * you don't should to add META-INF to classpath. what you need is a folder (or jar) that contains it. why ? getResourceasStream("META-INF/*") will return classpath_entry/META-INF/* If you add "META-INF" folder to classpath, it "will be the entry" so META-INF/services/PluginClass for get resource as stram will be: /services/PluginClass ( missin first element META-INF ) so wha tyou need is SomeFolder/META-INF/services/PluginClass. then add "SomeFolder" to classpath. you can just add META-INF folder inside "share/" and now META-INF will be found with the classloader.. * the last thing, is that share/plugins isn't at classpath. all files/folders inside plugins, are "dynamically" loaded by a Custom classloader. so if you want use this folder to add the plugins, you need to add subfolders: share/plugins/my_plugin_folder/META-INF/services/*... Or share/plugin/any_jar_file.jar/META-INF/* and the custom classloader will add "my_plugin_folder" to classpath ( if you add this folder to classpath with eclipse, you'll get 2 classpath entries, so the plugin will be loaded twoice ) Just remember that the classloader finds only what is "inside" the classpath.. and not the "root" folder.
Back to Top
Amedeo	Post: Jan 11th 2009 at 9:22 AM   Well this is how it works (or seems to be working) for me... Let's say we are working with the converter plugin. 1) Create a "TuxGuitar-converter" folder inside "TuxGuitar/share/plugins" 2) Copy the "META-INF" folder from "tuxguitar-converter.jar" inside it. 3) In Eclipse, open the TuxGuitar project properties, select "Run/Debug settings", edit the "TGMain" launch configuration, select "classpath", select "User Entries", click "Advanced", select "Add external folder" and finally choose the "TuxGuitar-converter/bin" folder.
Back to Top
Julian	Post: Jan 12th 2009 at 10:04 AM   Yes it is fine.. but i still suggest you use link source way instead of classes. there are some adventajes using sources.. If you add a class folder plugin/bin you are adding "compiled" files. it's something like as if you would add a .jar file. but, eclipse don't see it as a project. I mean, if you have TuxGuitar + TuxGuitar-plugin/bin when you make some change on the plugin, and then run tuxguitar. eclipse will not rebuild the plugin classes (well yes if you have the auto build option enabled) So you'll need 1_ go to plugin, click build project 2_ go to tuxguitar, click run. Now, if you link sources, eclipse does some kind of "shortcut". TuxGuitar/src ( these are original sources ) TuxGuitar/plugin-src (these are the plugin shortcut sources ) this new folder, is taked as a source folder of tuxguitar project. so when you click run on tuxguitar, eclipse will compile automatically the sources of plugin. The other point of add sources, is "debug". if you add class folder, at debug time, eclipse don't have idea where are the plugin sources. and if it's true that you can "configure it". you don't need any configuration for it if you link sources. You can just test it. go to TuxGuitar properties, select "Java Build Path" and on "Source" tab, click the "Link Source" button. then select "plugin/src" and on folder name ( as default you'll see error, because src is duplicated ) set any other name to this folder.. such as "converter-src" Ofcrouse if you do this, remember remove the previouslly classpath entry that you did.
Back to Top
Amedeo	Post: Jan 16th 2009 at 3:05 PM   OK, I finally did it right!
Back to Top

Post Reply