From
Dima Kozlov
→
To
All
1 February 2006
Hello SMT
SMT> you write plugins in C/C++? You can also link statically. true
SMT> DLL is good because you can independently update plugins and the player
look at the root! in addition, you can have one copy of the dll in the system and update
only her...
SMT> actually, it’s too early to share the skin of an unkilled bear, there’s still an interface
SMT> is not even ready.
I agree, in the end, if the interface is stable enough, the wrapper
You can do it once by hand...
SMT> now I think the module needs a list of properties that can be
SMT> read, and those that can be edited
but it would be nice to whisper on this topic with Sergei Bulba...
From
Stanislav Lomakin
→
To
All
2 February 2006
Hello elf/2
from xmms-plugin...
unzip, make “make plugin”, copy the resulting libvtxplay.so to
directory where xmms keeps input plugins.
(for me it is /usr/lib/xmms/Input)
By the way, it turns out that there is already one vtx-xmms-plugin for Linux %)
Tuta: http://sashnov.nm.ru/ayengine.html
and the AY/YM emulation library is also there
hmm, citizens whose ears do not come out of their butts^H^H^H^H armpits grow - what do you think?
Which emulation is more similar to hardware? :rolleyes:
File: vtxplay_n_xmms.zip http://zx.pk.ru/attachment.php?attachmentid=2526
From
Slavik Tretiak
→
To
All
2 February 2006
Hello, boo_boo
does it only play vtx?
From
Slavik Tretiak
→
To
All
2 February 2006
Hello, boo_boo
Well then I'll wait, because in vtx I have exactly 1 Mouzon ^_~
From
Stanislav Lomakin
→
To
All
2 February 2006
Hello Sinus
Sin> does it only play vtx?
well yes. SMT will make the announced Song class with all sorts of different formats,
there will be the rest ;)
From
Stanislav Lomakin
→
To
All
16 February 2006
Hello SMT
SMT> most of this is due to the lack of support for nameless structs/unions in the description
SMT> Z80
well, yes, at least this seems to be the only thing that requires intervention in
code, and not just in the declaration.
From
Stanislav Lomakin
→
To
All
16 February 2006
Hello SMT
SMT> As for the Z80, I don’t know how it will work under Linux. try yours if
SMT> will not work unreal
He doesn’t get ready right away, obviously - he swears at a bunch of things, not only in the z80. as with
I'll clear it up in time and take a closer look. ...and in MSVC there is no compatibility mode with
ANSI/ISO C++? ;)
From
Stanislav Lomakin
→
To
All
16 February 2006
Hello SMT
SMT> send me the compilation log and I'll take a look...
here is the log :)
File: err.zip http://zx.pk.ru/attachment.php?attachmentid=2606
From
SMT
→
To
All
9 March 2006
Hello SMT
Fixed a glitch with desynchronization of AY and other sound sources (bepeer,
tape, etc), added the SNDCOUNTER class to determine how many samples
completely ready (when generated from several sources) and where from
The internal buffer must take these samples. example of use - in file
sndcounter.h
File: sndrender.rar http://zx.pk.ru/attachment.php?attachmentid=2793
From
Stanislav Lomakin
→
To
All
9 March 2006
Hello SMT
hurray, everything works :)
By the way, a suggestion - why not make the EXTERNAL_BUFFER mode standard? then
It is possible to pass a pointer to the buffer and its length to start_frame. IMHO with this
nothing else is needed in the layout - it completely replaces the current default
mode. and now in order to enable EXTERNAL_BUFFER, you have to go into the sources (as
defining it and then including *.h and *.cpp in the file is inconvenient, especially if
there is more than one file like this :)
From
SMT
→
To
All
9 March 2006
Hello SMT
> by the way, a suggestion - why not make the EXTERNAL_BUFFER mode
> full-time?
because 1) they can convey size - not a power of two and 2) will be lost
several tens of cycles inside the buffer filling cycle due to variables
instead of constants (MSVC optimizes actions with constants perfectly)
> now to enable EXTERNAL_BUFFER, you have to go into the sources
It’s clear, I specifically put this in a separate file sndbuffer.h - that’s enough
fix 1-2 lines there - indicate which variable contains the buffer
z.y. Now you can simplify sound processing a little - call start_frame without
parameter, ignore the result of end_frame (see example), the SNDCOUNTER object itself
counts everything
From
Stanislav Lomakin
→
To
All
9 March 2006
Hello SMT
SMT> because 1) they can convey size - not a power of two
not degree 2 and you can specify define :rolleyes:
SMT> it’s clear, I specifically put this in a separate file sndbuffer.h -
SMT> it is enough to correct 1-2 lines there - indicate in which variable
SMT> buffer lies
then you still need to move #include "sndcounter.h" to the very top in sndcounter.cpp,
and in sndcounter.h add #include "sndbuffer.h" before ifdef
hmm... if performance is important, you can make templates with
constant parameters: it will not become slower, edit the code when using
you won’t have to at all, and if you need to work with several buffers (maybe
useful in players, etc.) nothing will interfere.
PS sorry for the tediousness, I’m just a maniac when it comes to interfaces when I see
excellent code, I really want the interface to be all like itself :rolleyes:
From
SMT
→
To
All
9 March 2006
Hello SMT
> is not a degree of 2 and can be specified by definition
and worse, they can transfer different buffers and sizes each time, when everything
must be the same for SNDCOUNTER to work correctly
From
SMT
→
To
All
9 March 2006
Hello SMT
> is not a degree of 2 and can be specified by definition
I have already added this to sndrender.h:
┌─- CODE ───
#ifdef SND_EXTERNAL_BUFFER
#if ((SND_EXTERNAL_BUFFER_SIZE & (SND_EXTERNAL_BUFFER_SIZE-1)) != 0)
#pragma error("SND_EXTERNAL_BUFFER_SIZE must be power of 2")
#endif
#endif
└── CODE ───
> then you still need to #include "sndcounter.h" in sndcounter.cpp to
> very top
I agree
> and in sndcounter.h add #include "sndbuffer.h" before ifdef
enabled via #include "sndrender.h", which should be moved to the top
> hmm... if performance is important, you can make templates with
> constant parameters: it will not become slower if you use the code
> you won’t have to edit at all, and if you need to do it with several
> work with buffers (can be useful in players, etc.) nothing
> will interfere
it’s possible, but you have to think about it - you also need to create a buffer class and use it as
a template parameter so that all SNDRENDERS with the same buffer are the same
class
From
Stanislav Lomakin
→
To
All
9 March 2006
Hello SMT
SMT> and worse, they can transfer different buffers and sizes each time,
SMT> when everything must be the same for SNDCOUNTER to work correctly
if a pointer to a buffer and its size are passed as template parameters, do not
they can... and, by the way, in this case, you’ll just get one class for everything
SNDRENDERS using one buffer.