Menu
▾
▴
ultrastar-ng-devel — Ultrastar-ng devel mailing list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(62) |
Feb
(61) |
Mar
(33) |
Apr
(48) |
May
(46) |
Jun
(25) |
Jul
(12) |
Aug
(41) |
Sep
(20) |
Oct
(55) |
Nov
(56) |
Dec
(3) |
| 2008 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lasse K. <tro...@tr...> - 2010-07-30 07:23:53
|
Port to N900 would certainly be nice and it is something that I have hoped for, but that I cannot contribute to, as I don't have the hardware. The few bits of OpenGL in Performous could be rather easily rewritten in GLES 2.0 but we have so far not done that because Intel drivers don't support OpenGL shaders and we do not have the resources for supporting two completely different graphics platforms. We should probably continue about this on our irc channel as this list (like its performous-devel counterpart) is in deed quite dead. On 29.07.2010 21:45, Stefan Kristiansson wrote: > Hello, > I did some halfassed tries to make it run on the Nokia N900 and > I was able to compile it after commenting away some big chunks of the > OpenGL code and linking it > to the OpenGL ES libraries. > Alot of work would be needed to port the OpenGL code to OpenGL ES 2.0. > Unfortunately I don't have any time to continue on that. > |
|
From: Stefan K. <st...@la...> - 2010-07-29 19:34:16
|
Hi again... Please disregard this if anyone happens to see it, I have no other reason answering to 2 year old messages and even on a discontinued list, than that my mail client went amok and started to download all my old mail and showing them as new..... Stefan On 07/29/2010 09:45 PM, Stefan Kristiansson wrote: > Hello, > I did some halfassed tries to make it run on the Nokia N900 and > I was able to compile it after commenting away some big chunks of the > OpenGL code and linking it > to the OpenGL ES libraries. > Alot of work would be needed to port the OpenGL code to OpenGL ES 2.0. > Unfortunately I don't have any time to continue on that. > > Stefan Kristiansson > > On 11/10/2008 04:02 PM, Richard Hartmann wrote: > >> On Sun, Nov 9, 2008 at 16:23, Lasse Kärkkäinen<tro...@tr...> wrote: >> >> >> >>> The game has been successfully used on P3-733 with 256 MB RAM and GF2 >>> MX400, with still 5 % CPU idle. >>> >>> >> Sounds good. >> >> >> >> >>> You will need hardware OpenGL, though, otherwise the game will be way >>> too slow. >>> >>> >> OpenGL EL 2.0 is supported. That is a subset of the full OpenGL specs. >> >> >> Richard >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK& win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Ultrastar-ng-devel mailing list >> Ult...@li... >> https://lists.sourceforge.net/lists/listinfo/ultrastar-ng-devel >> >> > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Ultrastar-ng-devel mailing list > Ult...@li... > https://lists.sourceforge.net/lists/listinfo/ultrastar-ng-devel > |
|
From: Stefan K. <st...@la...> - 2010-07-29 19:02:37
|
Hello, I did some halfassed tries to make it run on the Nokia N900 and I was able to compile it after commenting away some big chunks of the OpenGL code and linking it to the OpenGL ES libraries. Alot of work would be needed to port the OpenGL code to OpenGL ES 2.0. Unfortunately I don't have any time to continue on that. Stefan Kristiansson On 11/10/2008 04:02 PM, Richard Hartmann wrote: > On Sun, Nov 9, 2008 at 16:23, Lasse Kärkkäinen<tro...@tr...> wrote: > > >> The game has been successfully used on P3-733 with 256 MB RAM and GF2 >> MX400, with still 5 % CPU idle. >> > Sounds good. > > > >> You will need hardware OpenGL, though, otherwise the game will be way >> too slow. >> > OpenGL EL 2.0 is supported. That is a subset of the full OpenGL specs. > > > Richard > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK& win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Ultrastar-ng-devel mailing list > Ult...@li... > https://lists.sourceforge.net/lists/listinfo/ultrastar-ng-devel > |
|
From: Richard H. <ric...@gm...> - 2008-11-10 14:02:11
|
On Sun, Nov 9, 2008 at 16:23, Lasse Kärkkäinen <tro...@tr...> wrote: > The game has been successfully used on P3-733 with 256 MB RAM and GF2 > MX400, with still 5 % CPU idle. Sounds good. > You will need hardware OpenGL, though, otherwise the game will be way > too slow. OpenGL EL 2.0 is supported. That is a subset of the full OpenGL specs. Richard |
|
From: Lasse K. <tro...@tr...> - 2008-11-09 15:42:57
|
> I read that there were substantial performance increases in the new release. The game has been successfully used on P3-733 with 256 MB RAM and GF2 MX400, with still 5 % CPU idle. > Does Performous run on ARM processors? If yes, it would tie in _extremely_ > nicely with the Pandora [1]. The game itself is completely cross-platform, so if you can get all the libraries that we use (that are also fairly cross-platform) to run on your platform, then it should work. You will need hardware OpenGL, though, otherwise the game will be way too slow. |
|
From: Richard H. <ric...@gm...> - 2008-11-04 13:02:16
|
Hi all, I read that there were substantial performance increases in the new release. Does Performous run on ARM processors? If yes, it would tie in _extremely_ nicely with the Pandora [1]. Richard [1] openpandora.org |
|
From: Vincent Le L. <lel...@en...> - 2008-11-03 23:08:49
|
Hi,
All the team is proud to announce the immediate availability of
Performous (formerly known as UltraStar-NG) 0.3.0 version.
After one year and more that 700 svn commits it is finally out.
The major new features are : (copy from the website announce)
* Multiplayer with Singstar mics or any other stereo input
* Dramatically improved performance, runs fine on very slow machines now
* Fully OpenGL-based (some kind of 3D acceleration is now mandatory,
but even Intel works fine)
* Heavily pimped graphics in singing screen
* Automatically zooming notelines in singing screen
* Real widescreen support (adaptive layout instead of stretching or
cropping)
* Song folders are now scanned recursively, in the background
without blocking the UI
* Ingame and preview volume may be controlled
* Audio roundtrip latency and audio/video sync controls added
* New score window (still no highscores)
* New menu theme song
* Separate game engine thread, so that slow graphics rendering
should no longer affect pitch detection
* Our own audio library libda, supporting ALSA, Pulseaudio, JACK and
others
* FFMPEG-based video and audio decoding (together with libda
replaces Xine and GStreamer)
* CMake-based build (Autotools are gone for good)
* + too many others to list them all here
Big thanks to all the contributors and all the testers and all the
people involved in this release (and previous).
You can find useful informations here : http://performous.org/ on how to:
* Why we change name / the new features
* How to install the new games (from sources, Ubuntu deb files
provided by the project, svn)
* How to package Performous for your favorite distro
A 0.3.1 version is expected in the near future to fix the "few" issues
that this release could have (change from build chain to the graphics
and the sound engine...)
Please feel free to test it as much as you can and feedback any problem
or success you have on this mailing list or on the irc channel
(#performous on freenode).
The website: http://performous.org/
The source package:
http://downloads.sourceforge.net/performous/Performous-0.3.0-Source.tar.bz2
Again big thanks to everybody that make releasing possible today
(especially Tronic)
Vincent
PS: website is currently updating but should be quite up to date, please
report errors/typos/deadlinks
|
|
From: Vincent Le L. <lel...@en...> - 2008-05-26 19:19:14
|
Hi, Been a long time since no news have been given. Development is still going on even if Tronic and I have trouble finding free time :). About the news stuffs available: - Ffmpeg video support is now fully functionnal and keep original aspect ration (video is not stretched anymore when using non-4:3 ratio). - You can now resize the window while playing - The tools to extract Singstar DVD is working on my Singstar DVD (SingStar Pop Hits 2), but need full testing with others (many files are not located at the same place, and some xml are different. - The full game has been converted to OpenGL, a few thinks are still needed to be performed ; some themes need to be migrated to be fully opengl, themes need to be changed to support non-4:3 aspect ration (these are done into the hacking branch). - The website has been rewriten with new screenshots (please feel free to visit) - A new ultrastar-songs package has been released Todo things: - libda support for playback (with ffmpeg and portaudio) (milestone 0.3.0) - Full OpenGL and non-4:3 ratio support (milestone 0.3.0) - Multiplayer game engine (milestone 0.4.0) - In-game Singstar DVD read (milestone 0.4.0 or 0.5.0) - support for hi-score (no milestone) - document Singstar DVD format (with different versions depending on game product id About the in-game Singstar DVD read we should take legal issues into account (if anybody knows something about it). Maybe having this without some kind of plugin could be a good idea. So if you have any interest in improving the one part of the project (making videos, screenshots, website, testing, playing, coding) you are welcome. See You Vincent |
|
From: Lasse K. <tr...@tr...> - 2008-03-05 09:17:43
|
Hi,
We are going to drop SDL graphics support (2D rendering), in favor of
OpenGL-only solution that will ease the development, allow nicer
graphical effects and most importantly be much, MUCH, faster.
Only very old machines should need to use 2D rendering, but they are
otherwise too slow for running the game (2D rendering is quite heavy on
the CPU). Unfortunately, also some new machines currently require 2D
rendering as well, most notably machines with new ATI graphics adapters,
which do not have 3D acceleration (yet) with the radeonhd driver. Well,
life sucks. Don't buy unsupported hardware :/
However, ATI has released the specifications, so it should be only a
matter of time when the 3D acceleration appears.
One thing that will change with OpenGL is the texture loading process.
While we currently generally load stuff into SDL_Surfaces (bitmaps,
scaling them on load) and Cairo Surfaces (vector graphics) on startup
and then do a slow render with these (rastering or blitting them to
screen), the OpenGL-only solution will be different.
Some kind of OpenGL surface wrapper will be written (currently WIP).
This will allocate an OpenGL texture ID on its constructor and free the
ID on its destructor. The texture itself may be filled with a chosen
bitmap (usually done during construction, but updating it later is also
possible). Once uploaded to OpenGL, the buffer used for uploading can be
deallocated.
The rendering only binds the OpenGL texture by its ID, draws a rectangle
of a suitable size and OpenGL will handle scaling and blending the texture.
While at this, it would be sensible to do other graphics-related
cleanup. One problem to solve is that USNG currently only supports 4:3
displays and will stretch the image if the AR is something else.
First some background on how the current theme system works.
Themes are SVG images, so they are basically freely scalable. There are,
however, specific hot spots in them for drawing progress bars, etc.
These spots are specified in pixels, with the assumption that the screen
is 800x600 (the SVG resolution). Of course the actual renderering
resolution is usually something different, so we generally end up
applying correction factors to all coordinates.
int screenX = 100 * (m_width / 800.0);
In the above example we have SVG X coordinate 100 (hardcoded),
multiplied by a correction factor that consists of the actual screen
width (m_width) and the SVG width 800 (hardcoded).
We have had numerous rendering bugs because of this, and even though
currently there are no such issues, all the rendering code is
unnecessarily complex because of this.
The system does not support different AR or resizing the window, etc (at
the moment).
An alternative solution is to use device-independent coordinate system.
OpenGL can be setup to use any coordinates that we wish, so we could
arbitrarily choose to use the following:
(-0.5, 0.31) +-----------------------------------+ (0.5, 0.31)
| |
| |
| |
| |
| screen center |
| (0.0, 0.0) |
| |
| |
| |
| |
| |
(-0.5, -0.31) +-----------------------------------+ (0.5, -0.31)
With these the screen width would always be 1.0, no matter what
resolution or AR is used. The screen width varies with the AR. The
screen is 0.625 high (-0.31 .. 0.31) on 16:10 widescreen displays,
0.56 (-0.28 .. 0.28) on 16:9 displays,
0.75 (-0.38 .. 0.38) on 4:3 displays and
0.8 (-0.4 .. 0.4) on 5:4 displays.
Now, if we make the themes in dimensions 1.0 * 0.8, but so that there is
nothing important on top or bottom (safe region, that fits on all
displays, being 1.0 * 0.56), the themes can be rendered at fixed size to
these display coordinates. If the screen is wider, the top and bottom of
the theme will just get cut off automatically by OpenGL.
This kind of coordinates are already used for the video (in SVN trunk),
always scaling the video to fill the screen horizontally, and letting it
be whatever size is necessary vertically. Since the video is centered on
the screen, the origin being at screen center is also helpful.
The magic spots in the themes should be redesigned or recalculated into
this coordinate system, but then the correction factors are avoided
entirely. E.g. 100 SVG pixels from the left side becomes
-0.5 + 100 / 800 = -0.375 in device-independent coordinates. 100 SVG
pixels from the right side (SVG coordinate 700) is 0.375.
One issue with all this is that only using the 16:9 of the screen is
quite wasteful. Maybe we want to adapt to different displays and use the
space most efficiently on all? Possibly some things (e.g. the lyrics)
will be aligned to screen bottom instead of the center? These would
still require knowledge of screen height, instead of just blindly
rendering them. If themes are to be adapted as well, they need to be
redesigned correspondingly (splitting a screen into several smaller SVGs
instead of one fullscreen image).
One thing to consider is that most background images are designed for a
specific aspect ratio and may look incorrect if some of the now hidden
area is displayed.
This is not the only solution and we might still prefer keeping the
pixel coordinates instead of this system. If we use pixel coordinates,
there are still a few options: SVG pixels or actual pixels; origin at
center or in top-left corner. Gotta love the flexibility of OpenGL, eh? :)
|
|
From: Vincent Le L. <lel...@en...> - 2008-02-17 10:16:26
|
Hi, I've just finished a file extractor for singstar pak files and a mib to wav converter. To have the list of the files in a pak file ./extract /mnt/cdrom/pak_iop0.pak --list To extract a file from a pak file : ./extract /mnt/cdrom/pak_iop0.pak --extract "25360\music.mib" music.raw (be carefull of the '\') To decode the audio sound file into a raw PCM format ./adpcm_decode music.raw music.wav.raw To play the music mplayer -demuxer rawaudio -rawaudio format=0:rate=48000:channels=2 music.wav.raw This works at least on "Singstar Pop Hits 2" French version, if you succeed on other Singstar please let me know (decode shoul be a little bit more difficult to work on all Singstar). This is work in progress but I aim to implement : - a player that play in-pak files (no need to extract files, grab artist and title from the xml from other pak file, etc.) - implement in-game decoding (both lyrics and audio) to play singstar DVD with UltraStar-NG - decode Singstar video Bit thanks to gigaherz from the pcsx2 team (PS2 emulator) that helps me a lot for the audio decoding. Vincent PS : I will also try to write an abstract for the linuxtag 2008 about UltraStar-NG (call for paper deadline is february the 21th). PS2: Yes I know, I had to work on the ffmpeg audio/video implementation on UltraStar-NG first :) |
|
From: Matias H. <mat...@ya...> - 2008-02-07 11:31:00
|
Hi If you have the same songs as me, then the reason for Arctic Monkeys - I Bet you Look Good on the Dance Floor could be that the notes overlap: Line 93: (91-95) : 174 1 69 I : 176 1 69 don't : 175 1 69 know : 178 2 69 if : 180 1 67 you're It would be possible to automatically guess what it was supposed to be (like here - change 175 to 177), but ultrastarng rather tells you the error so that you can fix it yourself. It would be nice to have the choice between automatic repair and displaying the error, but that is not implemented. If you start ultrastarng from terminal, you'll see all the errors with line number. At least if you use the latest trunk version, don't know about the other one. Matias --- Ruben Grimm <rg...@we...> wrote: > Hi > I got the problem, that some of my songs placed into > the songs folder of > Ultrastar can't be recognized. > I can't see any reason for this. They're formatted > the same way the > other songs are. > > For example I got problems with: > > 3 Doors Down - When I'm Gone > Arctic Monkeys - I Bet you Look Good on the Dance > Floor > > Where could be a reason for this? > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio > 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ultrastar-ng-devel mailing list > Ult...@li... > https://lists.sourceforge.net/lists/listinfo/ultrastar-ng-devel > __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com |
|
From: Ruben G. <rg...@we...> - 2008-02-02 15:02:07
|
Hi I got the problem, that some of my songs placed into the songs folder of Ultrastar can't be recognized. I can't see any reason for this. They're formatted the same way the other songs are. For example I got problems with: 3 Doors Down - When I'm Gone Arctic Monkeys - I Bet you Look Good on the Dance Floor Where could be a reason for this? |
|
From: Vincent Le L. <lel...@en...> - 2008-02-02 08:19:57
|
Hi, Things didn't advance as fast as I want, but some new things has to be quoted. First, I will finally end my transfer between my two homes (for the moment my computer is on the floor and it is not very nice for coding (that's why I have trouble enhancing USNG). Transfer date: 23/02 Now news about USNG: - Debian package of 0.2.1 version has been made by getdeb team : http://www.getdeb.net/app/UltraStar-NG - Cover flow style has been added to the songs screen (should still be enhanced but is nice anyway) - OpenGL bug has been fixed. I finally fixed the OpenGL bug, now there is no more difference between SDL and opengl implementation :) :) :) :) That's all for the moment :) If you want to test/develop any new things you're free :) Vincent |
|
From: chriis <chr...@no...> - 2008-01-26 21:30:27
|
I've made the current cvs version and added a video. If i start that song ultrastar ended with a message. Then I converted the video with mencoder and ended in a black screen with working lyrics but no score, time and sing output. How can that happen? Second question: Is there a chance that a two player mode will be available soon? |
|
From: LE L. V. <lel...@en...> - 2008-01-16 13:52:45
|
Hi, Fews things happening the last month: - UltraStar-NG compiles and run under FreeBSD (one-liner patch was needed) - UltraStar-NG compiles and run under YellowDogLinux on PS3 (only the usb sincestar mic does not work). If you have one and want to test it please be free :) - ffmpeg video/audio decoding code is almost finished (small testing program is available on svn). Just need to write the output plugins for libda (could be a few months more). - Few bugs have been corrected (memleaks, fft things, etc.). - ArchLinux package has been updated - Gentoo package has been updated and now provides the ultrastar-songs packages (accessible via the use flag "songs"). - Gentoo dev ebuild (9999) has been updated to use svn instead of cvs (you can now install svn trunk using portage) - Added a few version checks (alsa, gstreamer) thanks to the very old YellowDogLinux distro and display of record backend configured at the end of the configure script. Things that I hope do to for next news mail: - Add libda playback plugins: gstreamer, portaudio (v18 & v19), pulseaudio - Add libda record plugin: pulseaudio - Use ffmpeg for video and audio playback in USNG Cheers Vincent |
|
From: <tro...@tr...> - 2007-12-14 04:23:57
|
> For your reference, the standard Hamming window function is defined as : > w(n) = 0.53836 - 0.46164 * cos(2*pi*n / (N-1)) > > However, in USNG, the used Hamming window function is defined as : > w(n) = 0.53836 - 0.46164 * cos(2*pi*n / N - 1) Huh. This is clearly a bug :( Fixed in SVN now. I'm surprised that it doesn't seem to have much effect on the analyzer reliability and thus could go undetected so long. |
|
From: Eric W. <ir...@ms...> - 2007-12-14 04:01:00
|
Hi,=20
In record.cpp, it looks USNG is using a strange Hamming window function. =
Is it specially designed in this way ?
For your reference, the standard Hamming window function is defined as :
w(n) =3D 0.53836 - 0.46164 * cos(2*pi*n / (N-1))
However, in USNG, the used Hamming window function is defined as :
w(n) =3D 0.53836 - 0.46164 * cos(2*pi*n / N - 1)
Best Regards,
Eric Wang |
|
From: Vincent Le L. <lel...@en...> - 2007-12-09 08:51:10
|
Hi, Here are some news of what happens these last few weeks (mainly on #ultrastar-ng on freenode). Things have been done on code, mainly reduce C use in C++ program (deletes, malloc, and other things like that). Code is now more C++ than ever. I also take a time to learn boost library use. We also discuss a lot of things about ultrastar-ng's future with Tronic: 1. Global code organization, for the future it will help to split the code in different parts: - the display part - the sing part game engine - the global game engine (his leads to the next point) 2. Using this kind of code organization we could easily add other stuff to ultrastar-ng and made it a band game (adding guitar, drum, other stuffs) 3. Ultrastar-ng game's name will then became obsolete (new name is required) 4. LibDA, libDA is the library used for the moment for the record part, Tronic planned to implement more and more features in it (and I will help if I can), this will include audio playback (potentially using libavcodec/format/util) and basic (but complex) audio features (mixer, effects, computation, etc.). More than ever we need people for developing stuffs and specifying things, if you wanna help please come on the irc channel #ultrastar-ng on freenode, we will help you to get on the code (and you'll also can follow the discussions about the future of ultrastar-ng). Vincent PS: Tronic if you see some points that need to be changed/modified/enhanced in this email, please feel free (I'll try to make this one short and summarized) |
|
From: <arm...@o2...> - 2007-11-23 16:24:28
|
>=20>=20I=20hope=20it=20helps=20to=20explain=20my=20idea. >=20Yes.=20But=20why=20do=20you=20want=20such=20a=20feature=20in=20the=20= first=20place? Let=20me=20tell=20you=20a=20bit=20more=20about=20a=20bigger=20idea=20I=20= have... I=20know=20it=20is=20speculative=20and=20outright=20nuts=20but=20I=20thin= k=20it=20has=20a=20potential=20so=20why=20not=20share=20it. Lets=20assume=20UltraStar-NG=20is=20implemented=20in=20Java=20or=20Flash.= In=20such=20case=20you'd=20be=20eble=20to=20embed=20it=20in=20HTML,=20rig= ht=20underneath=20a=20YouTube=20video (embedded=20in=20the=20same=20HTML=20document). Now=20imagine=20a=20website=20where=20you=20can=20submit=20a=20pair=20of=20= URLs,=20for=20example: http://www.youtube.com/watch?v=3DYMmoXoJkojA http://johndoe.googlepages.com/IThinkImParanoid.txt=20(UltraStar's=20lyri= cs/tones=20file) The=20website=20would=20allow=20rating/browsing/whatever=20and=20of=20cou= rse=20display (via=20embedding=20YouTube=20and=20using=20embeddable=20UltraStar) How=20fast=20would=20the=20database=20of=20the=20links=20grow=20and=20how= =20big=20would=20it=20become? I=20know=20I'd=20love=20to=20have=20access=20to=20a=20website=20like=20th= at=20:) I=20develop=20a=20lot=20in=20Java=20and=20I=20know=20that=20it=20allows=20= to=20record=20samples=20from=20microphone=20as=20standard=20functionality= . Same=20goes=20to=20Flash.=20I=20know=20flash=20is=20slow=20but=20it=20all= ows=20to=20calculate=20FFT=20(unfortunately=20not=20on=20the=20data=20fro= m=20microphone=20but=20only=20on=20mp3=20or=20other=20audio=20accessible=20= with=20an=20URL,=20so=20maybe=20in=20next=20version) >=20Just=20using=20a=20system=20timer=20does=20not=20work;=20it=20gets=20= too=20off-sync=20after=20a >=20couple=20of=20minutes. That=20is=20indeed=20a=20challenge.=20But=20if=20I=20think=20about=20poss= iblie=20solutions I=20guess=20that=20could=20be=20taken=20into=20account=20when=20comparing= =20output=20of=20the=20FFT with=20the=20tones=20from=20the=20file=20-=20comparison=20could=20be=20do= ne=20for=20a=20range=20of=20displacements and=20best=20match=20would=20be=20used.=20This=20displacement=20would=20t= hen=20be=20used=20to compensate=20for=20the=20clock=20drift. >=20It=20would=20also=20help=20avoid=20copyright=20infringement=20 Well,=20some=20of=20the=20labels=20start=20to=20post=20the=20videos=20on=20= YouTube (though=20they=20are=20not=20embeddable=20:(=20)=20-=20for=20example=20th= e=20link=20abouve=20for=20an=20example. Well,=20just=20a=20idea... Greets, J Dnia=2023=20listopada=202007=201:04=20Fr=C3=A9d=C3=A9ric=20Lopez=20<frede= ric...@fr...>=20napisa=C5=82(a): >=20Lasse=20Karkkainen=20a=20=C3=A9crit=20: >=20>=20 >=20>=20The=20previous=20post=20suggested=20browser=20embedding=20as=20an= =20easier=20solution.=20I >=20>=20justified=20why=20it=20isn't.=20The=20reasons=20why=20downlo= ading=20the=20video=20is >=20>=20problematic=20were=20discussed=20in=20my=20earlier=20post. >=20>=20 >=20>=20This=20script=20was=20mentioned=20in=20that=20post. >=20 >=20Sorry,=20I've=20been=20a=20little=20late=20in=20the=20discussion= ,=20didn't=20know=20you=20 >=20already=20talked=20about=20that. >=20 >=20>=20I=20am=20sure=20that=20people=20rather=20pay=200.002=20euros=20fo= r=20the=20disk=20space=20than >=20>=20wait=20for=20the=20song=20to=20be=20downloaded=20(or=20at=20least= =20buffered)=20every=20time >=20>=20they=20sing=20it. >=20 >=20You=20made=20a=20point=20there... >=20 >=20---------------------------------------------------------------------= ---- >=20This=20SF.net=20email=20is=20sponsored=20by:=20Microsoft >=20Defy=20all=20challenges.=20Microsoft(R)=20Visual=20Studio=202005. >=20http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >=20=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >=20Ultrastar-ng-devel=20mailing=20list >=20U...@li... >=20https://lists.sourceforge.net/lists/listinfo/ultrastar-ng-devel >=20 |
|
From: <fre...@fr...> - 2007-11-23 00:04:05
|
Lasse Karkkainen a écrit : > > The previous post suggested browser embedding as an easier solution. I > justified why it isn't. The reasons why downloading the video is > problematic were discussed in my earlier post. > > This script was mentioned in that post. Sorry, I've been a little late in the discussion, didn't know you already talked about that. > I am sure that people rather pay 0.002 euros for the disk space than > wait for the song to be downloaded (or at least buffered) every time > they sing it. You made a point there... |
|
From: <fre...@fr...> - 2007-11-22 23:59:58
|
Lasse Karkkainen a écrit : > > I'm sure that they'll do. Most musicians seem to be happy to be asked to > do something like that :) You were right, I just asked one of my friends and he's ok to play the song on his piano and distribute it under a very liberal license. Thanks for the advice :) And tonight I found a candidate girl to pose for my Christmas theme after an Ultrastar Deluxe session with some friends. It was my first try at this game with a group of friends and it was great fun. Too bad so few people I know do use Linux though, I would have prefered to play with Ultrastar NG... |
|
From: Lasse K. <tro...@tr...> - 2007-11-22 10:14:09
|
> I don't understand why you would need this, do you need it for locally > stored videos ? Yes. We always need to be able to get the clock from the audio player (video players sync video to audio, too), because otherwise we cannot run the game at the correct rate. Just using a system timer does not work; it gets too off-sync after a couple of minutes. > You don't need to embed a browser and a flash interpreter, you just need > to be able to download the stream and play it directly with the > platform-dependant code you already use to display videos. The previous post suggested browser embedding as an easier solution. I justified why it isn't. The reasons why downloading the video is problematic were discussed in my earlier post. > There are a lot of scripts available on the Web that can do this, for > example : http://www.arrakis.es/~rggi3/youtube-dl/ This script was mentioned in that post. > Videos do eat a lot of disk space, with a feature like this you wouldn't > have to store the videos on your disk anymore. HDD is very cheap. One gigabyte of HDD costs 0.2 € and you can fit at least half a dozen music videos there, even if in high definition. With quality comparable to Youtube, you can fit more than 100 music videos in that space. I am sure that people rather pay 0.002 euros for the disk space than wait for the song to be downloaded (or at least buffered) every time they sing it. Torrents can do data distribution quite well, even in larger packages. > It would also help avoid copyright infringement since you don't store > the files on your disk. That is, if your local laws allow one to view > copyrighted content on YouTube. I don't think that this is the case in many countries and in the end your web browser will probably still cache the stuff on your HDD, not to mention using youtube-dl to actually download the files. Pretty much all countries seem to make even downloading from illegal source illegal. Others still allow downloading, as long as you don't distribute the stuff. |
|
From: Lasse K. <tro...@tr...> - 2007-11-22 09:54:24
|
> From my experience, the default Windows MIDI synthetizer is pure crap > compared to software synthetizers like Timidity. The quality of the > rendered music does only depend on the SoundFonts you use with it, not > on your soundcard or your MIDI synthetizer. It's not very realistic, but it sounds good and most importantly it is stable and reliable, so that it does not produce any kind of distortions. I have tried all software synths that I could find for Linux, with several soundfonts and all just have these horrible issues. Many will easily go unstable and produce very loud noise that has nothing to do with the original music. Others just produce clicks or otherwise bad sound quality. So, in order to redeem that problem, I actually ended up buying an el-cheapo Casio keyboard/synth that doesn't do more than 4 simultaneous tones and doesn't do those very well either, but that still beats the Linux software synths. > I've several friends who are musicians, but I didn't want to bother them > with that. I'm not sure they'll accept and allow me to distribute the > work under a permissive license, but it doesn't cost anything to ask. I'm sure that they'll do. Most musicians seem to be happy to be asked to do something like that :) > I do agree that the instruments may not sound as good as real > instruments, but what are the noise you are talking about ? I only heard > some clicks here and there, but nothing really that disturbing. Yes, those clicks. They are disturbing enough for me not to be able to use the song. |
|
From: <fre...@fr...> - 2007-11-21 21:34:26
|
Lasse Karkkainen a écrit : > > Try the MIDI synth that comes with Windows. It is excellent and easily > beats many commercial MIDI synths (from Yamaha for example). Timidity > and all other free synths that I have tried are pure crap, as > demonstrated by the distortion in the MP3 you have. From my experience, the default Windows MIDI synthetizer is pure crap compared to software synthetizers like Timidity. The quality of the rendered music does only depend on the SoundFonts you use with it, not on your soundcard or your MIDI synthetizer. I'll try again when I've got access to a Windows machine anyway, but I really doubt the situation has evolved... > Find someone who can play piano (asks the girls you know, many of them > took piano lessons as child) and record it yourself. Then ask permission > to use it under a suitable license. I've several friends who are musicians, but I didn't want to bother them with that. I'm not sure they'll accept and allow me to distribute the work under a permissive license, but it doesn't cost anything to ask. > Do a sound check with your recording equipment before doing the actual > recording so that you don't get noise like the one that I got in the > menu music :/ I do agree that the instruments may not sound as good as real instruments, but what are the noise you are talking about ? I only heard some clicks here and there, but nothing really that disturbing. |
|
From: <fre...@fr...> - 2007-11-21 20:52:30
|
Lasse Karkkainen a écrit : > > We still need to be able to get timing information (clock) from the > player, which AFAIK is not possible. I don't understand why you would need this, do you need it for locally stored videos ? > Not to mention the actual painting > of the thing and supporting it separately on each platform because > browser + Flash embedding is not exactly cross-platform (even with Gecko). You don't need to embed a browser and a flash interpreter, you just need to be able to download the stream and play it directly with the platform-dependant code you already use to display videos. There are a lot of scripts available on the Web that can do this, for example : http://www.arrakis.es/~rggi3/youtube-dl/ > Yes. But why do you want such a feature in the first place? Videos do eat a lot of disk space, with a feature like this you wouldn't have to store the videos on your disk anymore. It would also help avoid copyright infringement since you don't store the files on your disk. That is, if your local laws allow one to view copyrighted content on YouTube. |
2 messages has been excluded from this view by a project administrator.
