Re: [jokosher-devel] SoC 2007
It would be definetly good idea, because Gstreamer needs lot of improvements, which would directly benefit Jokosher and others - improved ALSA support for high end cards, primitive MIDI support, etc. Just my two cents, Peter 2007/2/18, Edward Hervey [EMAIL PROTECTED]: Hey all, Wouldn't it make more sense to put jokosher, gstreamer, pitivi and other gstreamer-based projects under one GStreamer umbrella project ? Last year we screwed up the timing to register GStreamer as a project, but this time I'm sure we can prepare a solid proposal. Edward On 2/16/07, Jono Bacon [EMAIL PROTECTED] wrote: Yep folks, Its out again, do you think we should register as a project? Jono ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list -- Edward Hervey Multimedia editing developer / Fluendo S.A. http://www.pitivi.org/ ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
Re: [jokosher-devel] [PATCH] Fixed solo button behaviour
I disagree about such functionality. For example, Cubase allows to have solos on as much instruments as you want. Therefore with Solo fuction you can cherry pick channels for playing them together. Otherwise you would have to silent rest of channels which is quite foolish. Just my 2 cents, Peteris Krisjanis. 2007/6/18, Knut Erik Teigen [EMAIL PROTECTED]: Hello again, I noticed that if you have soloed an instrument, when you press the solo button of another instrument, the previous instrument will still have solo status. The intuitive behavior is that if another instrument gets solo status, the solo status for the original instrument will be disabled. I've added code so that when the solo button is pressed, any other instruments with solo status are unsoloed. Regards, Knut Erik Teigen ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
Re: [jokosher-devel] [PATCH] Fixed solo button behaviour
I strongly disagree that it is un-discoverable. Everyone who have worked with computer for some time knows that CTRL is multiple selection. My pick about usability of Jokosher is that we are trying to achieve some new ground here. Staying with old errors (like multiple solo selections *by default*), in my opinion, is not right. For information and avoiding confusion we could have tool tip on button Solo, which informs about possibility to select multiple channels with CTRL. Again, of course, it is just my two bits of though, cheers, Peter. 2007/6/20, Nick Murtagh [EMAIL PROTECTED]: On 20/06/07, Panos Laganakos [EMAIL PROTECTED] wrote: 2. If I hold down Ctrl+click, I can set more than one channel to solo. Which is, of course, completely un-discoverable... this is why multiple-select dropdowns are a bad idea (a list of items with checkboxes is better). ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
[jokosher-devel] Jokosher test team meeting, Sunday, 9th September, 6 pm/18:00 UTC
Topics for a meeting: 1. Test designing - how to create complete test suite (known also as QA check list) for Jokosher in reasonable time frame; 2. Testing and reporting - how to do regular testing with our spare resources, what kind of tools to use, suggestions, automatisation; 3. Deadlines and expectation - when actual stuff should be delivered; Everyone with interest in doing actual testing stuff are welcome, Peteris Krisjanis ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
[jokosher-devel] Jokosher bug review, fall 2007 aka Long time no post
Hi everyone! I hope we haven't thrown a towel and given up. For some kick-start to revitalize Jokosher development, I did some Jokosher bug review, to see big picture. Using Launchpad bug list and testing additionally Jokosher with newest Gst CVS, I have made three clearly separated groups of bugs: 1. Most important ones, as seems to me, are seeking bugs, as they usually ends with crashes and freezees. For now, most visible ones is: a) import FLAC file, split in five, seven or more pieces and make them separated with few sec of silence, playback and then do seeking without pressing stop; b) import FLAC/MP3 file, play it and after playhead has reached end, seek it back (without pressing stop) for 5 secs and do it several times. FLAC produce freeze after three four times, MP3 produced crash after some six times, but I was unable to reproduce later; c) also with FLAC, playing back without seeking forwards and backwards is OK, however when I start to do actively seeking forward/backward _while playing_, first it confuses pieces (plays another one instead of first one) and later, crashes or freezes; After extensive testing, it seems that seeking problems mostly affects FLAC; MP3 seeking crashes are less predictable and rather hard to reproduce, but they happen. Ogg Vorbis however drops some sec from beginning of each seperated piece, and have imprecise waveforms, but it survives insane seeking test and don't produce freeze/crash. At the time of testing WAV seeking was broken in Gstreamer CVS, but thanks to efforts Gstreamer team, it was fixed in one day and so it works like a charm again, so no bugs here. In short, seeking is good in Wav, Ogg Vorbis (however, it has waveforms are out of order, and beginning of pieces are not played back); random, but rare crashes/freezes with MP3; FLAC seeking bugs are reproducible quite easy. 2. Second is general playback/record problems, First of all, Ogg Vorbis streams (which is default dump format by know) playbacks/records very badly if there is more than just one instrument added to project (cracks, hisses, etc), waveforms are also out of order, and start of pieces are not played back. None of this doesn't affect FLAC, MP3 and Wav. End of recording gets snapped for FLAC and Ogg Vorbis. Also I think error dialog informing that there is some problem with playback/record pipeline should be revised, also we need to stop pipeline and clear the field, because now it stops, issues error dialog, but still has some lingering processes in background. After these two groups it seems that it would be sane to set WAV as default dump format for now. Of course, work on improving support for rest of formats should continue, as people will import lot of mp3/oggs/flacs into their projects. Maybe we can import them as WAV too. 3. Gstreamer/ALSA problems. After still unable to playback anything with my multichannel sound card, I did a little research for myself what 'plughw' device actually means. In result, I got Jokosher to playback with custom 'alsasink device=plughw:2' string. However, it failed to playback when I choosed ALSA and then device. I hope it's not serious bug though. So if we fix Jokosher to playback everything trough plughw to any device, it should work. With recording there is kinda simple situation - recording from device with one mono channel works and that's it. I haven't tried to record from line in, but it should work too, after converted to mono. However, something with more channels are showstopper. Again, also see suggestion about playback/recording error dialogs above. Further issues: 5. Multichannel import and recording - when doing import of mp3, I thought, what a heck, it does convert it to mono. Sometimes it is enough, but sometimes it would rock to have stereo file converted to two Audio File instruments. Probably some pop-up dialog/warning would be enough. Stereo recording would be more difficult and would require the same deinterleave element as multichannel sound cards. It is possible to have many channels in Ogg Vorbis, for example. 6. Accelerated graphics - as far as I understand, we use Cairo, but it has to be explicitly set to use hardware acceleration backend. How we can deal with this? Waveforms in fact are OK even now, but VU meters sure is lagging like a hell. :) As I wanted to post this as soon as possible, I will send another mail with more detailed bug information, like report numbers. Cheers, Peteris Krisjanis. ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
Re: [jokosher-devel] bzr?
I will attend it. Haven't been much time to test and work on Jokosher since resolution of deinterleave bug, but I will try to do something about it next week. Peter. Since we will be hosting code on launchpad now, we will have to decide what to do with the wiki on python hosting. Is next sunday a good day for everyone to have a freeze meeting and wiki discussion? Laszlo ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
Re: [jokosher-devel] Crash recovery dialog
I would like to point out that current wording of dialog is somehow confusing. Question in embedded dialog asks about current project, but user sees project is already opened. What gets recovered then? Usually it means lost recording, editing, etc. It could be described work done before last save or something like that. Otherwise - nice feature, keep rockin Laszlo! Cheers, Peter. 2009/2/15 Laszlo Pandy laszl...@gmail.com: I have fixed up a few more things in the crash recovery system such as recordings. Now it won't wait until after the recording completes to log the action. ie. If Jokosher crashes while recording, everything recorded up to that point will still be recovered. I have put in a message area to prompt for recovery. I would just like to see if anyone has comments on the message presented to users: http://laszlopandy.com/files/jokosher-recovery-pane.png Also it is perfectly fine if the user ignores the dialog and doesn't click close. Once they start working on the project and moving events/instruments, etc the message area will disappear on its own (since we can't recover a project after its been changed without destroying the users work). So this feature is ready to be merged. Any comments? Laszlo ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
Re: [jokosher-devel] Wiki
2009/3/12 Jeff Ratliff jef...@gmail.com: My googling shows most people switch from MoinMoin to MediaWiki because Moin is limited to about 32000 pages. I don't see us every getting anywhere near these limits. If we're just trying to improve speed, I don't think switching software is the answer. It's pretty easy to reconfigure what we've got to make it faster. We'd need some other reasons to switch to justify the work. Also MediaWiki lacks significant features that we use (like ACLs and Docbook support). 2009/3/12 Laszlo Pandy laszl...@gmail.com: I was gonna suggest mediawiki too, but I thought it would be too much trouble to setup yet another wiki. I would also second Jeff - MoinMoin performance is easily improvable with fastcgi version (as I use it in my work). If someone need real life administrator's support to set up it, feel free to write me/ping me trough Google Talk. Cheers, Peter. ___ jokosher-devel-list mailing list jokosher-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
