From: rokus <el...@go...> - 2006-06-17 12:50:41
|
first: what about a new release? i know nothing about the releaseplan but a new release with at least utf-support and the new plugins would be great (i (and maybe others) are too lazy to compile cvs-versions). all the bleeding-edge-stuff (automation etc.) could be left out. second: there is this lmms-devel list but no lmms-user list. instead those questions are also answered here. i would suggest either a new lmms-user list or a renaming of this list to lmms (without any addition). third: i'd like to have an "export"-feature to have all the samples used in a song are embedded into the mmp-file. the location of the samples are saved with an absolute path, therefore working on one song on different computers is a pain. so far the wishes of an user :) -- http://rosarauschen.tk |
From: Javier S. P. <ja...@te...> - 2006-06-19 14:17:57
|
En/na Tobias Doerffel ha escrit: > Am Samstag, 17. Juni 2006 14:50 schrieb rokus: >> first: what about a new release? i know nothing about the releaseplan but a >> new release with at least utf-support and the new plugins would be great (i >> (and maybe others) are too lazy to compile cvs-versions). all the >> bleeding-edge-stuff (automation etc.) could be left out. > yeah, that's right, I also thought about that in the past few days... I don't > know what the others say... currently undo/redo-system is buggy and > incomplete, that would be the only thing that would keep me away from making > a new release... There're a lot of improvements. There're also a lot of bugs, then it's not releasable, but we aren't in 1.0 and it's usable, so a new release would be fine :) My problem is I'm in the middle of the automation stuff and won't be able to help. If you decide to go ahead let me upgrade those organic presets before. Then there's libsamplerate, it should be a requirement. Fixes weren't applied to non-libsamplerate code. Bye. |
From: Tobias D. <tob...@gm...> - 2006-06-26 12:31:58
|
Am Montag, 19. Juni 2006 16:22 schrieb Javier Serrano Polo: > There're a lot of improvements. There're also a lot of bugs, then it's > not releasable, but we aren't in 1.0 and it's usable, so a new release > would be fine :) > My problem is I'm in the middle of the automation stuff and won't be > able to help. If you decide to go ahead let me upgrade those organic > presets before. what exactly are you doing at the moment? it would be fine if you would inf= orm=20 us from time to time about the state of your work, especially for avoiding= =20 conflicts with other developers, because they might to the same thing... There're also some other things to change: currently you pass pointers to=20 floats (or whatever) to oscillator-class, but in my opinion it should be=20 pointers to automatableObject<TYPE> and use their value()-method. This is=20 much more generic. The only thing is, that some code in tripleosc etc. has = to=20 be rewritten, as they calculate the final value from the knobs-value. As=20 knob, all button-classes etc. are derived from automatableObject<...> it'd = be=20 more logical to use pointers on them instead of "3rd-party-data" ;-)=20 Otherwise things get too complex very soon... > Then there's libsamplerate, it should be a requirement. Fixes weren't > applied to non-libsamplerate code. is it a lot of work to fix them? then it'd be better to fix them... otherwi= se=20 we could add a serious warning to configure informing about the issue.. beside that I would prepare a release within this week, even if it won't be= =20 perfect and complete, but it's better and more stable than 0.1.4 for sure!= =20 and that's important... toby =2D-=20 Lebensk=FCnstler sind Menschen, die sich auf das =DCberfl=FCssige beschr=E4nken. -- Werner Mitsch |
From: Tobias D. <tob...@gm...> - 2006-06-27 11:15:37
|
Am Montag, 26. Juni 2006 15:30 schrieben Sie: > If you don't want the automation stuff, please tell me. I was going to > upload it this evening. I think it's worth a couple of days delay. woah! great job!!!!!!!! this is (almost) exactly what I always dreamed of := =2D)=20 one thing: especially for wide-ranged knobs, it's very unconvenient to draw= =20 some stuff, as even 25% scaling is too small, so I think there should be do= ne=20 some automatic scaling inside the editor, so that at least at 25% it really= =20 displays everything. another small (internal) thing is the naming of classe= s=20 etc. in my opinion something=20 like "automation-editor", "automation-pattern", "automation-track" would=20 describe their tasks much better... may be you can also find a better=20 solution for controlling the level-stuff, i.e. not using an extra-class=20 levelObject. I know that it's some kind of tricky as automatableObject is a= =20 template-class and pointers on them can't be mixed, but maybe a=20 helper-class/helper-methods inside automatableObject for some "magical=20 casting" (or whatever... :-) could be made up... but so far I wouldn't care= =20 too much about that, as it works now. The only thing I would like to be add= ed=20 before the release is a context-menu for automatable buttons and=20 button-groups where you can open the time-roll ("automation-editor" ;-) thanks again for this great work! toby =2D-=20 Allem kann ich widerstehen, nur der Versuchung nicht. -- Oscar Wilde |
From: Javier S. P. <ja...@te...> - 2006-06-27 14:51:33
|
En/na Tobias Doerffel ha escrit: > woah! great job!!!!!!!! this is (almost) exactly what I always dreamed of :-) > one thing: especially for wide-ranged knobs, it's very unconvenient to draw > some stuff, as even 25% scaling is too small, so I think there should be done > some automatic scaling inside the editor, so that at least at 25% it really > displays everything. Yes, I know. I should notice this isn't really intended to be a final version, just to let other developers know what's being done, receive feedback, etc. *IMPORTANT* I've realized the new file format isn't robust enough. Don't make any serious project yet. I'm working on a fix. *IMPORTANT* > another small (internal) thing is the naming of classes > etc. in my opinion something > like "automation-editor", "automation-pattern", "automation-track" would > describe their tasks much better... There was already an automation pattern around. But we can still change those names. Should I do it? > may be you can also find a better > solution for controlling the level-stuff, i.e. not using an extra-class > levelObject. I know that it's some kind of tricky as automatableObject is a > template-class and pointers on them can't be mixed, but maybe a > helper-class/helper-methods inside automatableObject for some "magical > casting" (or whatever... :-) could be made up... but so far I wouldn't care > too much about that, as it works now. I don't know any better solution. C++ doesn't have interfaces as in Java, we only have multi-inheritance. In this sense, templates are evil. Maybe we could use a QVariant based class instead of templates but... it already works. > The only thing I would like to be added > before the release is a context-menu for automatable buttons and > button-groups where you can open the time-roll There's a lot to do: add the option to the tempo sync knobs, surrounding areas... > ("automation-editor" ;-) Ok, I'll change the names :) > thanks again for this great work! You're welcome. Thanks for making the app in the first place. Bye. |
From: Tobias D. <tob...@gm...> - 2006-06-19 07:48:24
|
Am Samstag, 17. Juni 2006 14:50 schrieb rokus: > first: what about a new release? i know nothing about the releaseplan but= a > new release with at least utf-support and the new plugins would be great = (i > (and maybe others) are too lazy to compile cvs-versions). all the > bleeding-edge-stuff (automation etc.) could be left out. yeah, that's right, I also thought about that in the past few days... I don= 't=20 know what the others say... currently undo/redo-system is buggy and=20 incomplete, that would be the only thing that would keep me away from makin= g=20 a new release... > second: there is this lmms-devel list but no lmms-user list. instead those > questions are also answered here. i would suggest either a new lmms-user > list or a renaming of this list to lmms (without any addition). that's right too, will create a new list then... > third: i'd like to have an "export"-feature to have all the samples used = in > a song are embedded into the mmp-file. the location of the samples are > saved with an absolute path, therefore working on one song on different > computers is a pain. also something I already thought about... actually we'd just need to save a= ll=20 samples base64-encoded into the XML-file and compress the file afterwards (= gz=20 or whatever...) toby =2D-=20 Die meisten unserer Fehler sind verzeihlicher als die Mittel, die wir anwenden, um sie zu verbergen. -- Fran=E7ois de La Rochefoucauld |