diff options
| author | Timothy Pearson <kb9vqf@pearsoncomputing.net> | 2011-12-03 11:05:10 -0600 |
|---|---|---|
| committer | Timothy Pearson <kb9vqf@pearsoncomputing.net> | 2011-12-03 11:05:10 -0600 |
| commit | f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b (patch) | |
| tree | 1f78ef53b206c6b4e4efc88c4849aa9f686a094d /tde-i18n-de/docs/tdemultimedia/artsbuilder | |
| parent | 85ca18776aa487b06b9d5ab7459b8f837ba637f3 (diff) | |
| download | tde-i18n-f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b.tar.gz tde-i18n-f7e7a923aca8be643f9ae6f7252f9fb27b3d2c3b.zip | |
Second part of prior commit
Diffstat (limited to 'tde-i18n-de/docs/tdemultimedia/artsbuilder')
20 files changed, 10785 insertions, 0 deletions
diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/Makefile.am b/tde-i18n-de/docs/tdemultimedia/artsbuilder/Makefile.am new file mode 100644 index 00000000000..df6332b8050 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/Makefile.am @@ -0,0 +1,4 @@ +KDE_LANG = de +SUBDIRS = $(AUTODIRS) +KDE_DOCS = AUTO +KDE_MANS = AUTO diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/Makefile.in b/tde-i18n-de/docs/tdemultimedia/artsbuilder/Makefile.in new file mode 100644 index 00000000000..5425492fe7a --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/Makefile.in @@ -0,0 +1,635 @@ +# Makefile.in generated by automake 1.10.1 from Makefile.am. +# KDE tags expanded automatically by am_edit - $Revision: 483858 $ +# @configure_input@ + +# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, +# 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. +# This Makefile.in is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, to the extent permitted by law; without +# even the implied warranty of MERCHANTABILITY or FITNESS FOR A +# PARTICULAR PURPOSE. + +@SET_MAKE@ +VPATH = @srcdir@ +pkgdatadir = $(datadir)/@PACKAGE@ +pkglibdir = $(libdir)/@PACKAGE@ +pkgincludedir = $(includedir)/@PACKAGE@ +am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd +install_sh_DATA = $(install_sh) -c -m 644 +install_sh_PROGRAM = $(install_sh) -c +install_sh_SCRIPT = $(install_sh) -c +INSTALL_HEADER = $(INSTALL_DATA) +transform = $(program_transform_name) +NORMAL_INSTALL = : +PRE_INSTALL = : +POST_INSTALL = : +NORMAL_UNINSTALL = : +PRE_UNINSTALL = : +POST_UNINSTALL = : +subdir = docs/tdemultimedia/artsbuilder +DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in +ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 +am__aclocal_m4_deps = $(top_srcdir)/acinclude.m4 \ + $(top_srcdir)/configure.in +am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ + $(ACLOCAL_M4) +mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs +CONFIG_HEADER = $(top_builddir)/config.h +CONFIG_CLEAN_FILES = +SOURCES = +DIST_SOURCES = +#>- RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \ +#>- html-recursive info-recursive install-data-recursive \ +#>- install-dvi-recursive install-exec-recursive \ +#>- install-html-recursive install-info-recursive \ +#>- install-pdf-recursive install-ps-recursive install-recursive \ +#>- installcheck-recursive installdirs-recursive pdf-recursive \ +#>- ps-recursive uninstall-recursive +#>+ 7 +RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \ + html-recursive info-recursive install-data-recursive \ + install-dvi-recursive install-exec-recursive \ + install-html-recursive install-info-recursive \ + install-pdf-recursive install-ps-recursive install-recursive \ + installcheck-recursive installdirs-recursive pdf-recursive \ + ps-recursive uninstall-recursive nmcheck-recursive bcheck-recursive +RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive \ + distclean-recursive maintainer-clean-recursive +ETAGS = etags +CTAGS = ctags +DIST_SUBDIRS = $(SUBDIRS) +#>- DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) +#>+ 1 +DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) $(KDE_DIST) +ACLOCAL = @ACLOCAL@ +AMTAR = @AMTAR@ +ARTSCCONFIG = @ARTSCCONFIG@ +AUTOCONF = @AUTOCONF@ +AUTODIRS = @AUTODIRS@ +AUTOHEADER = @AUTOHEADER@ +AUTOMAKE = @AUTOMAKE@ +AWK = @AWK@ +CONF_FILES = @CONF_FILES@ +CYGPATH_W = @CYGPATH_W@ +DCOPIDL = @DCOPIDL@ +DCOPIDL2CPP = @DCOPIDL2CPP@ +DCOPIDLNG = @DCOPIDLNG@ +DCOP_DEPENDENCIES = @DCOP_DEPENDENCIES@ +DEFS = @DEFS@ +ECHO_C = @ECHO_C@ +ECHO_N = @ECHO_N@ +ECHO_T = @ECHO_T@ +GMSGFMT = @GMSGFMT@ +INSTALL = @INSTALL@ +INSTALL_DATA = @INSTALL_DATA@ +INSTALL_PROGRAM = @INSTALL_PROGRAM@ +INSTALL_SCRIPT = @INSTALL_SCRIPT@ +INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ +KCFG_DEPENDENCIES = @KCFG_DEPENDENCIES@ +KCONFIG_COMPILER = @KCONFIG_COMPILER@ +KDECONFIG = @KDECONFIG@ +KDE_EXTRA_RPATH = @KDE_EXTRA_RPATH@ +KDE_RPATH = @KDE_RPATH@ +KDE_XSL_STYLESHEET = @KDE_XSL_STYLESHEET@ +LIBOBJS = @LIBOBJS@ +LIBS = @LIBS@ +LN_S = @LN_S@ +LTLIBOBJS = @LTLIBOBJS@ +MAKEINFO = @MAKEINFO@ +MAKEKDEWIDGETS = @MAKEKDEWIDGETS@ +MCOPIDL = @MCOPIDL@ +MEINPROC = @MEINPROC@ +MKDIR_P = @MKDIR_P@ +MSGFMT = @MSGFMT@ +PACKAGE = @PACKAGE@ +PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@ +PACKAGE_NAME = @PACKAGE_NAME@ +PACKAGE_STRING = @PACKAGE_STRING@ +PACKAGE_TARNAME = @PACKAGE_TARNAME@ +PACKAGE_VERSION = @PACKAGE_VERSION@ +PATH_SEPARATOR = @PATH_SEPARATOR@ +SET_MAKE = @SET_MAKE@ +SHELL = @SHELL@ +STRIP = @STRIP@ +TOPSUBDIRS = @TOPSUBDIRS@ +VERSION = @VERSION@ +XGETTEXT = @XGETTEXT@ +XMLLINT = @XMLLINT@ +X_RPATH = @X_RPATH@ +abs_builddir = @abs_builddir@ +abs_srcdir = @abs_srcdir@ +abs_top_builddir = @abs_top_builddir@ +abs_top_srcdir = @abs_top_srcdir@ +am__leading_dot = @am__leading_dot@ +am__tar = @am__tar@ +am__untar = @am__untar@ +#>- bindir = @bindir@ +#>+ 2 +DEPDIR = .deps +bindir = @bindir@ +build_alias = @build_alias@ +builddir = @builddir@ +datadir = @datadir@ +datarootdir = @datarootdir@ +docdir = @docdir@ +dvidir = @dvidir@ +exec_prefix = @exec_prefix@ +host_alias = @host_alias@ +htmldir = @htmldir@ +includedir = @includedir@ +infodir = @infodir@ +install_sh = @install_sh@ +kde_appsdir = @kde_appsdir@ +kde_bindir = @kde_bindir@ +kde_confdir = @kde_confdir@ +kde_datadir = @kde_datadir@ +kde_htmldir = @kde_htmldir@ +kde_icondir = @kde_icondir@ +kde_kcfgdir = @kde_kcfgdir@ +kde_libs_htmldir = @kde_libs_htmldir@ +kde_libs_prefix = @kde_libs_prefix@ +kde_locale = @kde_locale@ +kde_mimedir = @kde_mimedir@ +kde_moduledir = @kde_moduledir@ +kde_servicesdir = @kde_servicesdir@ +kde_servicetypesdir = @kde_servicetypesdir@ +kde_sounddir = @kde_sounddir@ +kde_styledir = @kde_styledir@ +kde_templatesdir = @kde_templatesdir@ +kde_wallpaperdir = @kde_wallpaperdir@ +kde_widgetdir = @kde_widgetdir@ +tdeinitdir = @tdeinitdir@ +libdir = @libdir@ +libexecdir = @libexecdir@ +localedir = @localedir@ +localstatedir = @localstatedir@ +mandir = @mandir@ +mkdir_p = @mkdir_p@ +oldincludedir = @oldincludedir@ +pdfdir = @pdfdir@ +prefix = @prefix@ +program_transform_name = @program_transform_name@ +psdir = @psdir@ +sbindir = @sbindir@ +sharedstatedir = @sharedstatedir@ +srcdir = @srcdir@ +sysconfdir = @sysconfdir@ +target_alias = @target_alias@ +top_builddir = @top_builddir@ +top_srcdir = @top_srcdir@ +xdg_appsdir = @xdg_appsdir@ +xdg_directorydir = @xdg_directorydir@ +xdg_menudir = @xdg_menudir@ +KDE_LANG = de +#>- SUBDIRS = $(AUTODIRS) +#>+ 1 +SUBDIRS =. +KDE_DOCS = AUTO +KDE_MANS = AUTO +#>- all: all-recursive +#>+ 1 +all: docs-am all-recursive + +.SUFFIXES: +$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps) +#>- @for dep in $?; do \ +#>- case '$(am__configure_deps)' in \ +#>- *$$dep*) \ +#>- cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \ +#>- && exit 0; \ +#>- exit 1;; \ +#>- esac; \ +#>- done; \ +#>- echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu docs/tdemultimedia/artsbuilder/Makefile'; \ +#>- cd $(top_srcdir) && \ +#>- $(AUTOMAKE) --gnu docs/tdemultimedia/artsbuilder/Makefile +#>+ 12 + @for dep in $?; do \ + case '$(am__configure_deps)' in \ + *$$dep*) \ + cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \ + && exit 0; \ + exit 1;; \ + esac; \ + done; \ + echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu docs/tdemultimedia/artsbuilder/Makefile'; \ + cd $(top_srcdir) && \ + $(AUTOMAKE) --gnu docs/tdemultimedia/artsbuilder/Makefile + cd $(top_srcdir) && perl ../scripts/admin/am_edit -p../scripts/admin docs/tdemultimedia/artsbuilder/Makefile.in +.PRECIOUS: Makefile +Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status + @case '$?' in \ + *config.status*) \ + cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \ + *) \ + echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \ + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \ + esac; + +$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES) + cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh + +$(top_srcdir)/configure: $(am__configure_deps) + cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh +$(ACLOCAL_M4): $(am__aclocal_m4_deps) + cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh + +# This directory's subdirectories are mostly independent; you can cd +# into them and run `make' without going through this Makefile. +# To change the values of `make' variables: instead of editing Makefiles, +# (1) if the variable is set in `config.status', edit `config.status' +# (which will cause the Makefiles to be regenerated when you run `make'); +# (2) otherwise, pass the desired values on the `make' command line. +$(RECURSIVE_TARGETS): + @failcom='exit 1'; \ + for f in x $$MAKEFLAGS; do \ + case $$f in \ + *=* | --[!k]*);; \ + *k*) failcom='fail=yes';; \ + esac; \ + done; \ + dot_seen=no; \ + target=`echo $@ | sed s/-recursive//`; \ + list='$(SUBDIRS)'; for subdir in $$list; do \ + echo "Making $$target in $$subdir"; \ + if test "$$subdir" = "."; then \ + dot_seen=yes; \ + local_target="$$target-am"; \ + else \ + local_target="$$target"; \ + fi; \ + (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \ + || eval $$failcom; \ + done; \ + if test "$$dot_seen" = "no"; then \ + $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \ + fi; test -z "$$fail" + +$(RECURSIVE_CLEAN_TARGETS): + @failcom='exit 1'; \ + for f in x $$MAKEFLAGS; do \ + case $$f in \ + *=* | --[!k]*);; \ + *k*) failcom='fail=yes';; \ + esac; \ + done; \ + dot_seen=no; \ + case "$@" in \ + distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \ + *) list='$(SUBDIRS)' ;; \ + esac; \ + rev=''; for subdir in $$list; do \ + if test "$$subdir" = "."; then :; else \ + rev="$$subdir $$rev"; \ + fi; \ + done; \ + rev="$$rev ."; \ + target=`echo $@ | sed s/-recursive//`; \ + for subdir in $$rev; do \ + echo "Making $$target in $$subdir"; \ + if test "$$subdir" = "."; then \ + local_target="$$target-am"; \ + else \ + local_target="$$target"; \ + fi; \ + (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \ + || eval $$failcom; \ + done && test -z "$$fail" +tags-recursive: + list='$(SUBDIRS)'; for subdir in $$list; do \ + test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \ + done +ctags-recursive: + list='$(SUBDIRS)'; for subdir in $$list; do \ + test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \ + done + +ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES) + list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) '{ files[$$0] = 1; nonemtpy = 1; } \ + END { if (nonempty) { for (i in files) print i; }; }'`; \ + mkid -fID $$unique +tags: TAGS + +TAGS: tags-recursive $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \ + $(TAGS_FILES) $(LISP) + tags=; \ + here=`pwd`; \ + if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \ + include_option=--etags-include; \ + empty_fix=.; \ + else \ + include_option=--include; \ + empty_fix=; \ + fi; \ + list='$(SUBDIRS)'; for subdir in $$list; do \ + if test "$$subdir" = .; then :; else \ + test ! -f $$subdir/TAGS || \ + tags="$$tags $$include_option=$$here/$$subdir/TAGS"; \ + fi; \ + done; \ + list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) '{ files[$$0] = 1; nonempty = 1; } \ + END { if (nonempty) { for (i in files) print i; }; }'`; \ + if test -z "$(ETAGS_ARGS)$$tags$$unique"; then :; else \ + test -n "$$unique" || unique=$$empty_fix; \ + $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \ + $$tags $$unique; \ + fi +ctags: CTAGS +CTAGS: ctags-recursive $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \ + $(TAGS_FILES) $(LISP) + tags=; \ + list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \ + unique=`for i in $$list; do \ + if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \ + done | \ + $(AWK) '{ files[$$0] = 1; nonempty = 1; } \ + END { if (nonempty) { for (i in files) print i; }; }'`; \ + test -z "$(CTAGS_ARGS)$$tags$$unique" \ + || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \ + $$tags $$unique + +GTAGS: + here=`$(am__cd) $(top_builddir) && pwd` \ + && cd $(top_srcdir) \ + && gtags -i $(GTAGS_ARGS) $$here + +distclean-tags: + -rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags + +#>- distdir: $(DISTFILES) +#>+ 1 +distdir: distdir-nls $(DISTFILES) + @srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ + topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \ + list='$(DISTFILES)'; \ + dist_files=`for file in $$list; do echo $$file; done | \ + sed -e "s|^$$srcdirstrip/||;t" \ + -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \ + case $$dist_files in \ + */*) $(MKDIR_P) `echo "$$dist_files" | \ + sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \ + sort -u` ;; \ + esac; \ + for file in $$dist_files; do \ + if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \ + if test -d $$d/$$file; then \ + dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \ + if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \ + cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \ + fi; \ + cp -pR $$d/$$file $(distdir)$$dir || exit 1; \ + else \ + test -f $(distdir)/$$file \ + || cp -p $$d/$$file $(distdir)/$$file \ + || exit 1; \ + fi; \ + done + list='$(DIST_SUBDIRS)'; for subdir in $$list; do \ + if test "$$subdir" = .; then :; else \ + test -d "$(distdir)/$$subdir" \ + || $(MKDIR_P) "$(distdir)/$$subdir" \ + || exit 1; \ + distdir=`$(am__cd) $(distdir) && pwd`; \ + top_distdir=`$(am__cd) $(top_distdir) && pwd`; \ + (cd $$subdir && \ + $(MAKE) $(AM_MAKEFLAGS) \ + top_distdir="$$top_distdir" \ + distdir="$$distdir/$$subdir" \ + am__remove_distdir=: \ + am__skip_length_check=: \ + distdir) \ + || exit 1; \ + fi; \ + done +check-am: all-am +check: check-recursive +all-am: Makefile +installdirs: installdirs-recursive +installdirs-am: +install: install-recursive +install-exec: install-exec-recursive +install-data: install-data-recursive +#>- uninstall: uninstall-recursive +#>+ 1 +uninstall: uninstall-docs uninstall-nls uninstall-recursive + +install-am: all-am + @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am + +installcheck: installcheck-recursive +install-strip: + $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ + install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \ + `test -z '$(STRIP)' || \ + echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install +mostlyclean-generic: + +clean-generic: + +distclean-generic: + -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES) + +maintainer-clean-generic: + @echo "This command is intended for maintainers to use" + @echo "it deletes files that may require special tools to rebuild." +#>- clean: clean-recursive +#>+ 1 +clean: kde-rpo-clean clean-recursive + +#>- clean-am: clean-generic mostlyclean-am +#>+ 1 +clean-am: clean-docs clean-bcheck clean-generic mostlyclean-am + +distclean: distclean-recursive + -rm -f Makefile +distclean-am: clean-am distclean-generic distclean-tags + +dvi: dvi-recursive + +dvi-am: + +html: html-recursive + +info: info-recursive + +info-am: + +#>- install-data-am: +#>+ 1 +install-data-am: install-docs install-nls + +install-dvi: install-dvi-recursive + +install-exec-am: + +install-html: install-html-recursive + +install-info: install-info-recursive + +install-man: + +install-pdf: install-pdf-recursive + +install-ps: install-ps-recursive + +installcheck-am: + +maintainer-clean: maintainer-clean-recursive + -rm -f Makefile +maintainer-clean-am: distclean-am maintainer-clean-generic + +mostlyclean: mostlyclean-recursive + +mostlyclean-am: mostlyclean-generic + +pdf: pdf-recursive + +pdf-am: + +ps: ps-recursive + +ps-am: + +uninstall-am: + +.MAKE: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) install-am \ + install-strip + +.PHONY: $(RECURSIVE_CLEAN_TARGETS) $(RECURSIVE_TARGETS) CTAGS GTAGS \ + all all-am check check-am clean clean-generic ctags \ + ctags-recursive distclean distclean-generic distclean-tags \ + distdir dvi dvi-am html html-am info info-am install \ + install-am install-data install-data-am install-dvi \ + install-dvi-am install-exec install-exec-am install-html \ + install-html-am install-info install-info-am install-man \ + install-pdf install-pdf-am install-ps install-ps-am \ + install-strip installcheck installcheck-am installdirs \ + installdirs-am maintainer-clean maintainer-clean-generic \ + mostlyclean mostlyclean-generic pdf pdf-am ps ps-am tags \ + tags-recursive uninstall uninstall-am + +# Tell versions [3.59,3.63) of GNU make to not export all variables. +# Otherwise a system limit (for SysV at least) may be exceeded. +.NOEXPORT: + +#>+ 2 +KDE_DIST=future.docbook index.docbook porting.docbook glossary.docbook helping.docbook artsbuilder.docbook detail.docbook midiintro.docbook modules.docbook mcop.docbook gui.docbook faq.docbook index.cache.bz2 midi.docbook tools.docbook Makefile.in digitalaudio.docbook references.docbook apis.docbook Makefile.am + +#>+ 24 +index.cache.bz2: $(srcdir)/index.docbook $(KDE_XSL_STYLESHEET) glossary.docbook porting.docbook apis.docbook gui.docbook references.docbook mcop.docbook index.docbook detail.docbook future.docbook artsbuilder.docbook digitalaudio.docbook faq.docbook modules.docbook tools.docbook midi.docbook helping.docbook midiintro.docbook + @if test -n "$(MEINPROC)"; then echo $(MEINPROC) --check --cache index.cache.bz2 $(srcdir)/index.docbook; $(MEINPROC) --check --cache index.cache.bz2 $(srcdir)/index.docbook; fi + +docs-am: index.cache.bz2 + +install-docs: docs-am install-nls + $(mkinstalldirs) $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder + @if test -f index.cache.bz2; then \ + echo $(INSTALL_DATA) index.cache.bz2 $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/; \ + $(INSTALL_DATA) index.cache.bz2 $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/; \ + elif test -f $(srcdir)/index.cache.bz2; then \ + echo $(INSTALL_DATA) $(srcdir)/index.cache.bz2 $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/; \ + $(INSTALL_DATA) $(srcdir)/index.cache.bz2 $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/; \ + fi + -rm -f $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/common + $(LN_S) $(kde_libs_htmldir)/$(KDE_LANG)/common $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/common + +uninstall-docs: + -rm -rf $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder + +clean-docs: + -rm -f index.cache.bz2 + + +#>+ 13 +install-nls: + $(mkinstalldirs) $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder + @for base in glossary.docbook porting.docbook apis.docbook gui.docbook references.docbook mcop.docbook index.docbook detail.docbook future.docbook artsbuilder.docbook digitalaudio.docbook faq.docbook modules.docbook tools.docbook midi.docbook helping.docbook midiintro.docbook ; do \ + echo $(INSTALL_DATA) $$base $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/$$base ;\ + $(INSTALL_DATA) $(srcdir)/$$base $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/$$base ;\ + done + +uninstall-nls: + for base in glossary.docbook porting.docbook apis.docbook gui.docbook references.docbook mcop.docbook index.docbook detail.docbook future.docbook artsbuilder.docbook digitalaudio.docbook faq.docbook modules.docbook tools.docbook midi.docbook helping.docbook midiintro.docbook ; do \ + rm -f $(DESTDIR)$(kde_htmldir)/$(KDE_LANG)/artsbuilder/$$base ;\ + done + + +#>+ 5 +distdir-nls: + for file in glossary.docbook porting.docbook apis.docbook gui.docbook references.docbook mcop.docbook index.docbook detail.docbook future.docbook artsbuilder.docbook digitalaudio.docbook faq.docbook modules.docbook tools.docbook midi.docbook helping.docbook midiintro.docbook ; do \ + cp $(srcdir)/$$file $(distdir); \ + done + +#>+ 15 +force-reedit: + @for dep in $?; do \ + case '$(am__configure_deps)' in \ + *$$dep*) \ + cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \ + && exit 0; \ + exit 1;; \ + esac; \ + done; \ + echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu docs/tdemultimedia/artsbuilder/Makefile'; \ + cd $(top_srcdir) && \ + $(AUTOMAKE) --gnu docs/tdemultimedia/artsbuilder/Makefile + cd $(top_srcdir) && perl ../scripts/admin/am_edit -p../scripts/admin docs/tdemultimedia/artsbuilder/Makefile.in + + +#>+ 21 +clean-bcheck: + rm -f *.bchecktest.cc *.bchecktest.cc.class a.out + +bcheck: bcheck-recursive + +bcheck-am: + @for i in ; do \ + if test $(srcdir)/$$i -nt $$i.bchecktest.cc; then \ + echo "int main() {return 0;}" > $$i.bchecktest.cc ; \ + echo "#include \"$$i\"" >> $$i.bchecktest.cc ; \ + echo "$$i"; \ + if ! $(CXX) $(DEFS) -I. -I$(srcdir) -I$(top_builddir) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(CXXFLAGS) $(KDE_CXXFLAGS) --dump-class-hierarchy -c $$i.bchecktest.cc; then \ + rm -f $$i.bchecktest.cc; exit 1; \ + fi ; \ + echo "" >> $$i.bchecktest.cc.class; \ + perl $(top_srcdir)/admin/bcheck.pl $$i.bchecktest.cc.class || { rm -f $$i.bchecktest.cc; exit 1; }; \ + rm -f a.out; \ + fi ; \ + done + + +#>+ 3 +final: + $(MAKE) all-am + +#>+ 3 +final-install: + $(MAKE) install-am + +#>+ 3 +no-final: + $(MAKE) all-am + +#>+ 3 +no-final-install: + $(MAKE) install-am + +#>+ 3 +kde-rpo-clean: + -rm -f *.rpo + +#>+ 3 +nmcheck: +nmcheck-am: nmcheck diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/apis.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/apis.docbook new file mode 100644 index 00000000000..331fa1482d6 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/apis.docbook @@ -0,0 +1,434 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="arts-apis"> +<title +>&arts; Application Programming Interfaces</title> + +<sect1 id="api-overview"> +<title +>Überblick</title> +<para +>aRts is not only a piece of software, it also provides a variety of APIs for a variety of purposes. In this section, I will try to describe the "big picture", a brief glance what those APIs are supposed to do, and how they interact. </para> + +<para +>There is one important distinction to make: most of the APIs are <emphasis +> language and location independent</emphasis +> because they are specified as <emphasis +>mcopidl</emphasis +>. That is, you can basically use the services they offer from any language, implement them in any language, and you will not have to care whether you are talking to local or remote objects. Here is a list of these first: </para> + + +<variablelist> +<varlistentry> +<term +>core.idl</term> + <listitem +><para +>Basic definitions that form the core of the MCOP functionality, such as the protocol itself, definitions of the object, the trader, the flow system and so on. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsflow.idl</term> + + <listitem +><para +>These contain the flow system you will use for connecting audio streams, the definition of <emphasis +>Arts::SynthModule</emphasis +> which is the base for any interface that has streams, and finally a few useful audio objects </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>kmedia2.idl</term> + + + <listitem +><para +>Here, an object that can play a media, <emphasis +>Arts::PlayObject</emphasis +> gets defined. Media players such as the KDE media player noatun will be able to play any media for which a PlayObject can be found. So it makes sense to implement PlayObjects for various formats (such as mp3, mpg video, midi, wav, ...) on that base, and there are a lot already. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>soundserver.idl</term> + + <listitem +><para +>Here, an interface for the system wide sound server artsd is defined. The interface is called <emphasis +>Arts::SoundServer</emphasis +>, which implements functionality like accepting streams from the network, playing samples, creating custom other aRts objects and so on. Network transparency is implied due to the use of MCOP (as for everything else here). </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsbuilder.idl</term> + <listitem +><para +>This module defines basic flow graph functionality, that is, combining simpler objects to more complex ones, by defining a graph of them. It defines the basic interface <emphasis +>Arts::StructureDesc</emphasis +>, <emphasis +>Arts::ModuleDesc</emphasis +> and <emphasis +>Arts::PortDesc</emphasis +> which contain a description of a structure, module, and port. There is also a way to get a "living network of objects" out of these connection and value descriptions, using a factory. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsmidi.idl</term> + + <listitem +><para +>This module defines basic midi functionality, like objects that produce midi events, what is a midi event, an <emphasis +>Arts::MidiManager</emphasis +> to connect the producers and consumers of midi events, and so on. As always network transparency implied. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsmodules.idl</term> + <listitem +><para +>Here are various additional filters, oscillators, effects, delays and so on, everything required for real useful signal processing, and to build complex instruments and effects out of these basic building blocks. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsgui.idl</term> + + <listitem +><para +>This cares about visual objects. It defines the basic type <emphasis +> Arts::Widget</emphasis +> from which all GUI modules derive. This will produce toolkit independency, and ... visual GUI editing, and serializable GUIs. Also, as the GUI elements have normal attributes, their values can be straight forward connected to some signal processing modules. (I.e. the value of a slider to the cutoff of a filter). As always: network transparent. </para +></listitem> + +</varlistentry> + +</variablelist> +<para +>Where possible, aRts itself is implemented using IDL. On the other hand, there are some <emphasis +>language specific</emphasis +> APIs, using either plain C++ or plain C. It is usually wise to use IDL interfaces where possible, and the other APIs where necessary. Here is a list of language specific APIs: </para> + +<variablelist> + +<varlistentry> +<term +>KNotify, KAudioPlayer (included in libtdecore)</term> + + <listitem +><para +>These are convenience KDE APIs for the simple and common common case, where you just want to play a sample. The APIs are plain C++, Qt/KDE optimized, and as easy as it can get. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>libartsc</term> + <listitem +><para +>Plain C interface for the sound server. Very useful for porting legacy applications. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>libmcop</term> + + <listitem +><para +>Here all magic for MCOP happens. The library contains the basic things you need to know for writing a simple MCOP application, the dispatcher, timers, iomanagement, but also the internals to make the MCOP protocol itself work. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>libartsflow</term> + <listitem +><para +>Besides the implementation of artsflow.idl, some useful utilities like sampling rate conversion. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>libqiomanager</term> + + <listitem +><para +>Integration of MCOP into the Qt event loop, when you write Qt applications using MCOP. </para +></listitem> + +</varlistentry> + +</variablelist> + + + +</sect1> +<sect1 id="knotify"> +<title +>knotify</title> +<para +>Noch nicht geschrieben. </para> +</sect1> + +<sect1 id="kaudioplayer"> +<title +>kaudioplayer</title> +<para +>Noch nicht geschrieben. </para> +</sect1> + +<sect1 id="libkmid"> +<title +>libkmid</title> +<para +>Noch nicht geschrieben. </para> +</sect1> + +<sect1 id="kmedia2"> +<title +>kmedia2</title> +<para +>Noch nicht geschrieben. </para> +</sect1> + +<sect1 id="soundserver"> +<title +>sound server</title> +<para +>Noch nicht geschrieben. </para> +</sect1> + +<sect1 id="artsflow"> +<title +>artsflow</title> +<para +>Noch nicht geschrieben. </para> +</sect1> + +<sect1 id="capi"> +<title +>C <acronym +>API</acronym +></title> + +<sect2 id="capiintro"> +<title +>Einleitung</title> + +<para +>The &arts; C <acronym +>API</acronym +> was designed to make it easy to writing and port plain C applications to the &arts; sound server. It provides streaming functionality (sending sample streams to <application +>artsd</application +>), either blocking or non-blocking. For most applications you simply remove the few system calls that deal with your audio device and replace them with the appropriate &arts; calls.</para> + +<para +>I did two ports as a proof of concept: <application +>mpg123</application +> and <application +>quake</application +>. You can get the patches from <ulink url="http://space.twc.de/~stefan/kde/download/artsc-patches.tar.gz" +>here</ulink +>. Feel free to submit your own patches to the maintainer of &arts; or of multimedia software packages so that they can integrate &arts; support into their code.</para> + +</sect2> + +<sect2 id="capiwalkthru"> +<title +>Quick Walkthrough</title> + +<para +>Sending audio to the sound server with the <acronym +>API</acronym +> is very simple:</para> +<procedure> +<step +><para +>include the header file using <userinput +>#include <artsc.h></userinput +></para +></step> +<step +><para +>initialize the <acronym +>API</acronym +> with <function +>arts_init()</function +></para +></step> +<step +><para +>create a stream with <function +>arts_play_stream()</function +></para +></step> +<step +><para +>configure specific parameters with <function +>arts_stream_set()</function +></para +></step> +<step +><para +>write sampling data to the stream with <function +>arts_write()</function +></para +></step> +<step +><para +>close the stream with <function +>arts_close_stream()</function +></para +></step> +<step +><para +>free the <acronym +>API</acronym +> with <function +>arts_free()</function +></para +></step> +</procedure> + +<para +>Here is a small example program that illustrates this:</para> + +<programlisting +>#include <stdio.h> +#include <artsc.h> +int main() +{ + arts_stream_t stream; + char buffer[8192]; + int bytes; + int errorcode; + + errorcode = arts_init(); + if (errorcode < 0) + { + fprintf(stderr, "arts_init error: %s\n", arts_error_text(errorcode)); + return 1; + } + + stream = arts_play_stream(44100, 16, 2, "artsctest"); + + while((bytes = fread(buffer, 1, 8192, stdin)) > 0) + { + errorcode = arts_write(stream, buffer, bytes); + if(errorcode < 0) + { + fprintf(stderr, "arts_write error: %s\n", arts_error_text(errorcode)); + return 1; + } + } + + arts_close_stream(stream); + arts_free(); + + return 0; +} +</programlisting> +</sect2> + +<sect2 id="capiartscconfig"> +<title +>Compiling and Linking: <application +>artsc-config</application +></title> + +<para +>To easily compile and link programs using the &arts; C <acronym +>API</acronym +>, the <application +>artsc-config</application +> utility is provided which knows which libraries you need to link and where the includes are. It is called using</para> + +<screen +><userinput +><command +>artsc-config</command +> <option +>--libs</option +></userinput +> +</screen> + +<para +>to find out the libraries and </para> + +<screen +><userinput +><command +>artsc-config</command +> <option +>--cflags</option +></userinput +> +</screen> + +<para +>to find out additional C compiler flags. The example above could have been compiled using the command line:</para> + +<screen +><userinput +><command +>cc</command +> <option +>-o artsctest artsctest.c `artsc-config --cflags` `artsc-config --libs`</option +></userinput> + +<userinput +><command +>cc</command +> <option +>-o artsctest</option +> <option +>artsctest.c</option +> <option +>`artsc-config --cflags`</option +> <option +>`artsc-config --libs`</option +></userinput +> +</screen> + +</sect2> + +<sect2 id="c-api-reference"> +<title +>Library Reference</title> + +<para +>[TODO: generate the documentation for artsc.h using kdoc] </para> + +</sect2> + +</sect1> +</chapter> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/artsbuilder.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/artsbuilder.docbook new file mode 100644 index 00000000000..7b189cffc4f --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/artsbuilder.docbook @@ -0,0 +1,917 @@ +<chapter id="artsbuilder"> +<title +>&arts-builder;</title> + +<sect1 id="overview"> +<title +>Überblick</title> + +<para +>Wenn Sie &arts-builder; verwenden wollen, sollten Sie zuerste den Klangserver (&artsd;) starten. Normalerweise ist er bereits gestartet, wenn Sie &kde; 2.1 oder höher verwenden. Ansonsten können Sie ihn in &kcontrol; unter <menuchoice +><guilabel +>Sound & Multimedia</guilabel +><guilabel +>Sound-System</guilabel +></menuchoice +> zum automatischen Start einrichten. </para> + +<para +>Wenn Sie &arts; verwenden, startet es kleine Module. &arts-builder; ist ein Werkzeug zur Erstellung neuer Strukturen von kleinen verbundenen Modulen. Sie können die Module einfach innerhalb des Gitters anordnen. Wählen Sie dazu aus dem Menü <guimenu +>Module</guimenu +> aus und klicken Sie dann irgendwo im grün-grauen Bereich. </para> + +<para +>Module habe üblicherweise Kanäle (durch die Audiosignale hinein und hinaus gelangen). Um zwei Kanäle zu verbinden, klicken Sie auf den Ersten (dadurch wird er orange) und dann auf den Zweiten. Sie können einen Eingabekanal (auf der oberen Modulseite) nur mit einem Ausgabekanal (auf der unteren Modulseite) verbinden. Wenn Sie einem Kanal einen festen Werte geben wollen (oder einen Kanal trennen wollen) so doppelklicken Sie auf diesen. </para> + +</sect1> + +<sect1 id="artsbuilder-tutorial"> +<title +>Einführung</title> + +<sect2 id="step-1"> +<title +>Schritt 1</title> + +<para +>Starten Sie &arts-builder;. </para> + +<para +>Um die Ausgabe zu hören, benötigen Sie ein Synth_AMAN_PLAY-Modul. Sie erstellen ein solches Modul, indem Sie <menuchoice +> <guimenu +>Module</guimenu +> <guisubmenu +>Synthese</guisubmenu +> <guisubmenu +>SoundIO</guisubmenu +> <guisubmenu +>Synth_AMAN_PLAY</guisubmenu +> </menuchoice +> auswählen und auf einen freien Platz im Modulbereich klicken. Platzieren Sie das Modul unterhalb der fünften Linie, da wir noch einige Module oberhalb einfügen werden. </para> + +<para +>Das Modul hat die Parameter <parameter +>title</parameter +> und <parameter +>autoRestoreID</parameter +> (in der Nähe des linken Kanals) zur Identifikation. Um diese auszufüllen, doppelklicken Sie auf diese Kanäle, wählen Sie konstanter Wert und tippen Sie <userinput +>tutorial</userinput +> in das Eingabefeld. Klicken Sie auf <guibutton +>OK</guibutton +> zur Bestätigung. </para> + +<para +>Klicken Sie auf <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Struktur ausführen</guimenuitem +> </menuchoice +>. Sie hören bisher nichts. Das Abspielmodul benötigt irgendetwas als Eingabe. Wenn Sie der Stille eine Weile gelauscht haben, klicken Sie auf <guibutton +>OK</guibutton +> und gehen Sie zu Schritt 2 </para> +</sect2> + +<sect2 id="step-2"> +<title +>Schritt 2</title> + +<para +>Erstellen Sie ein Synth_WAVE_SIN-Modul (im Menü unter <menuchoice +> <guimenu +>Module</guimenu +> <guimenuitem +>Synthese</guimenuitem +> <guimenuitem +>Wellenformen</guimenuitem +> </menuchoice +>) und fügen Sie dieses Modul oberhalb von Synth_AMAN_PLAY ein (lassen Sie eine Zeile Platz dazwischen). </para> + +<para +>Wie Sie sehen, produziert dieses Modul eine Ausgabe, erfordert aber eine Position <guilabel +>pos</guilabel +> als Eingabe. Verbinden Sie zuerst die Ausgabe mit den Lautsprechern. Klicken Sie auf den Kanal <guilabel +>out</guilabel +> des Synth_WAVE_SIN-Modules und dann auf den Kanal <guilabel +>left</guilabel +> des Synth_AMAN_PLAY-Modules. Damit sind diese zwei Module verbunden. </para> + +<para +>Keiner der Oszillatoren in &arts; benötigt eine Frequenz als Eingabe, sondern nur eine Position innerhalb der Welle. Die Position muss zwischen 0 und 1 liegen. Das wird für ein Standard-Synth_WAVE_SIN-Modul auf den Bereich 0 bis 2*Pi umgerechnet. Um eine bestimmte Frequenz zu erzeugen, benötigen Sie ein Synth_FREQUENCY-Modul. </para> + +<para +>Erstellen Sie ein Synth_FREQUENCY-Modul (unter <menuchoice +> <guimenu +>Module</guimenu +> <guimenu +>Synthese</guimenu +> <guimenu +>Oszillation & Modulation</guimenu +> </menuchoice +>) und verbinden Sie den <quote +>pos</quote +>-Ausgang mit dem <quote +>pos</quote +>-Eingang des Synth_WAVE_SIN-Modules. Legen Sie den Frequenzeingang des Frequenzgenerators auf den konstanten Wert 440. </para> + + +<para +>Wählen Sie <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Struktur ausführen</guimenuitem +></menuchoice +>. Sie sollten einen Sinuston von 440 Hz in einem von Ihren Lautsprechern hören. Wenn Sie genug zugehört haben, klicken Sie auf <guibutton +>OK</guibutton +> und gehen Sie zu Schritt 3. </para> + +</sect2> + +<sect2 id="step-3"> +<title +>Schritt 3</title> + +<para +>Es würde sich besser anhören, wenn der Sinuston aus beiden Lautsprechern zu hören wäre. Verbinden Sie den rechten Eingang von Synth_PLAY auch mit dem Ausgang von Synth_WAVE_SIN. </para> + +<para +>Erstellen Sie ein Synth_SEQUENCE-Objekt (durch <menuchoice +> <guimenu +>Module</guimenu +> <guisubmenu +>Synthese</guisubmenu +> <guisubmenu +>Midi & Sequencing</guisubmenu +> </menuchoice +>). Es sollte am oberen Rand platziert werden. Wenn Sie mehr Platz benötigen, können Sie die anderen Module verschieben, indem Sie sie auswählen (um mehrere auszuwählen, verwenden Sie &Shift;) und mit der Maus bewegen. </para> + +<para +>Nun verbinden Sie den Frequenzausgaben von Synth_SEQUENCE mit dem Frequenzeingang des Synth_FREQUENCY-Moduls. Stellen Sie die Geschwindigkeit der Sequenz auf den konstanten Wert 0.13 (der Geschwindigkeitseingang ist der linke). </para> + +<para +>Geben Sie nun für den rechten Eingang (Sequenz) von Synth_SEQUENCE als konstanten Wert <userinput +>A-3;C-4;E-4;C-4</userinput +> ein. Das legt eine Sequenz fest. Mehr dazu finden Sie im Abschnitt Modulreferenz. </para> + +<note> +<para +>Synth_SEQUENCE benötigt <emphasis +>unbedingt</emphasis +> eine Sequenz und eine Geschwindigkeit. Ohne diese Angaben wird das Programm vermutlich abstürzen. </para> +</note> + +<para +>Wählen Sie <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Struktur ausführen</guimenuitem +> </menuchoice +>. Sie sollten nun eine nette Sequenz hören. Klicken Sie auf <guibutton +>OK</guibutton +> und gehen Sie zu Schritt 4. </para> +</sect2> + +<sect2 id="step-4"> +<title +>Schritt 4</title> + +<para +>Erstellen Sie ein Synth_PSCALE-Modul (durch <menuchoice +> <guimenu +>Module</guimenu +> <guisubmenu +>Synthese</guisubmenu +> <guisubmenu +>Hüllkurven</guisubmenu +> </menuchoice +>). Trennen Sie den Ausgang der SIN-Welle durch doppelklicken und auswählen von <guilabel +>nicht verbunden</guilabel +>. Verbinden Sie </para> + +<orderedlist +><listitem> +<para +>den SIN-Ausgang mit dem Eingang (inval) von PSCALE</para> +</listitem> +<listitem> +<para +>Den Ausgang von PSCALE mit dem linken Eingang von AMAN_PLAY</para> +</listitem> +<listitem> +<para +>den Ausgang von PSCALE mit dem rechten Eingang von AMAN_PLAY</para> +</listitem> +<listitem> +<para +>den SEQUENCE-Ausgang (pos) mit dem PSCAL-Eingang (pos).</para> +</listitem> +</orderedlist> + +<para +>Setzen Sie schließlich den Eingang top von PSCALE auf einen konstanten Wert, z.B. 0.1. </para> + +<para +>Das funktioniert folgendermaßen: Das Modul Synth_SEQUENCE gibt zusätzliche Informationen über die Position der gerade erklingenden Note, wobei 0 gerade gestartet und 1 beendet bedeutet. Das Modul Synth_PSCALE skaliert die Lautstärke des Audiostroms von 0 (Ruhe) über 1 (Originallautstärke) zurück zu 0 (Ruhe) abhängig von der Position. Die Position, an der die Maximallautstärke erklingen soll, kann als Positionswert (pos) angegeben werden. 0.1 bedeutet, das nach 10% der Note die Lautstärke ihren Maximalwert erreicht und danach der Ausklingvorgang startet. </para> + + +<para +>Wählen Sie <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Struktur ausführen</guimenuitem +> </menuchoice +>. Sie sollten nun eine nette Sequenz hören. Klicken Sie auf <guibutton +>OK</guibutton +> und gehen Sie zu Schritt 4. </para> + +</sect2> + +<sect2 id="step-5-starting-to-beam-data-around"> +<title +>Schritt 5: Daten sollen übertragen werden ;-)</title> + +<para +>Starten Sie &arts-builder; ein zweites Mal</para> + +<para +>Erstellen Sie ein Synth_AMAN_PLAY-Modul und benennen Sie es sinnvoll. Erstellen Sie ein Synth_BUS_DOWNLINK-Modul und:</para> + +<orderedlist> +<listitem> +<para +>benennen Sie den Synth_BUS_DOWNLINK-Bus mit dem Namen Audio (das ist nur ein Name, man könnte auch jeden anderen Name verwenden) </para> +</listitem> +<listitem> +<para +>Verbinden Sie den linken Ausgang von Synth_BUS_DOWNLINKmit dem linken Eingang von Synth_AMAN_PLAY </para> +</listitem> +<listitem> +<para +>Verbinden Sie den rechten Ausgang von Synth_BUS_DOWNLINK mit dem rechten Eingang von Synth_AMAN_PLAY </para> +</listitem> +</orderedlist> + +<para +>Wenn Sie die Struktur jetzt ausführen, hören Sie noch nichts. </para> + +<para +>Gehen Sie zurück zur ersten Struktur in der ersten Instanz von &arts-builder; mit dem Synth_WAVE_SIN-Modul und ersetzen Sie das Modul Synth_AMAN_PLAY durch ein Synth_BUS_UPLINK,-Modul und benennen Sie es Audio (oder den Namen, den Sie für die entsprechende Komponente in der zweiten Instanz von &arts-builder; verwendet haben). Um ein Modul zu löschen, wählen Sie es aus und wählen Sie <menuchoice +><guimenu +>Bearbeiten</guimenu +><guimenuitem +>Löschen</guimenuitem +></menuchoice +> aus dem Menü ( oder drücken Sie die <keycap +>Entfernen</keycap +>-Taste). </para> + +<para +>Wählen Sie <menuchoice +><guimenu +>Datei</guimenu +> <guilabel +>Struktur ausführen</guilabel +></menuchoice +>. Sie hören die Notensequenz wiedergegeben über die Bus-Verbindung. </para> + +<para +>Wenn Sie herausfinden wollen, wozu eine solche Funktion nützlich ist, klicken Sie auf <guibutton +>OK</guibutton +> ( in der Instanz, die das Synth_SEQUENCE-Modul enthält, die andere Struktur wird nicht verändert) und gehen Sie zu Schritt 6. </para> +</sect2> + +<sect2 id="step-6-beaming-for-advanced-users"> +<title +>Schritt 6 Übertragung für Fortgeschrittene</title> + +<para +>Wählen Sie <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Struktur umbenennen</guimenuitem +></menuchoice +> in der Instanz, die das Synth_SEQUENCE-Modul enthält und benennen Sie die Struktur Anleitung. Bestätigen Sie mit <guibutton +>OK</guibutton +>. </para> + +<para +>Wählen Sie <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Speichern</guimenuitem +> </menuchoice +> </para> + +<para +>Starten Sie eine weitere Instanz von &arts-builder; und wählen Sie <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Öffnen</guimenuitem +></menuchoice +> und laden Sie die Struktur Anleitung. </para> + +<para +>Nun wählen Sie im Menü <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Struktur ausführen</guimenuitem +></menuchoice +> in beiden Instanzen. Sie hören nun die gleiche Struktur zweimal. Abhängig von der Zeitverschiebung wird es mehr oder weniger glücklich klingen. </para> + +<para +>An dieser Stelle können Sie noch folgendes tun: Starten Sie &noatun; und spielen Sie einige <literal role="extension" +>mp3</literal +>-Dateien ab. Starten Sie &artscontrol; und wählen Sie <menuchoice +><guimenu +>Ansicht</guimenu +><guimenuitem +>Audiomanager anzeigen</guimenuitem +></menuchoice +>. Es wird &noatun; und ihre Struktur <quote +>Anleitung</quote +> angezeigt. Klicken Sie doppelt auf &noatun;. Daraufhin wird eine Liste der Ausgabegeräte angezeigt. Auch die Struktur wird mit aufgeführt. Sie können die Ausgabe von &noatun; über den Audio-Bus durch ihre Wiedergabestruktur leiten. </para> +</sect2> + +<sect2 id="step-7-midi-synthesis"> +<title +>Schritt 7: Midi-Synthese</title> + +<para +>Jetzt wollen wir den Sinusgenerator in ein wirkliches Musikinstrument verwandeln. Dazu benötigen Sie ein Gerät, das &MIDI;-Ereignisse an &arts; senden kann. Sie können ein externes Keyboard (wie im folgenden beschrieben wird) aber auch einen Sequenzer, der den Midi-bus unterstützt, wie &brahms; verwenden. </para> + +<para +>Beenden Sie zuerst alle überflüssigen Instanzen von &arts-builder;. Sie benötigen lediglich die Instanz mit dem Sinusgenerator. Wählen Sie dreimal <menuchoice +><guimenu +>Kanäle</guimenu +> <guisubmenu +>Audio-Eingangssignal erstellen</guisubmenu +></menuchoice +> und dreimal <menuchoice +><guimenu +>Kanäle</guimenu +> <guisubmenu +>Audio-Ausgangssignal erstellen</guisubmenu +></menuchoice +> und platzieren Sie die Module geeignet. </para> + +<para +>Wählen Sie <menuchoice +><guimenu +>Kanäle</guimenu +> <guilabel +>Positionen/Namen ändern</guilabel +></menuchoice +> und benennen Sie die Kanäle um in frequency(Frequenz), velocity(Lautstärke), pressed(gedrückt), left(links), right(rechts) und done(stopp) um. </para> + +<para +>Sie können nun das Modul Synth_SEQUENCE löschen und stattdessen den Frequenzeingangskanal mit dem Modul Synth_FREQUENCY-Eingang verbinden. Was soll nun mit dem pos-Eingang passieren?</para +> <para +>Dieser Eingang bleibt unbesetzt, da es keinen Algorithmus der Welt gibt, der vorausberechnen kann, wann ein Spieler die Taste des Keyboards, die er gerade gedrückt hat, wieder loslassen wird. Daher haben wir nur einen Parameter gedrückt stattdessen, der anzeigt, ob der Spieler die Taste noch gedrückt hält (gedrückt=1: Taste immer noch heruntergehalten; gedrückt=0: Taste losgelassen) </para> + +<para +>Das Synth_PSCALE-Objekt muss nun auch ersetzt werden. Ersetzen Sie es durch ein Synth_ENVELOPE_ADSR-Modul (durch <menuchoice +><guimenu +>Module</guimenu +><guisubmenu +>Synthese</guisubmenu +> <guisubmenu +>Hüllkurven</guisubmenu +></menuchoice +>). Verbinden Sie: </para> + +<orderedlist> +<listitem> +<para +>den Struktureingang mit dem Ausgang active von ADSR</para> +</listitem> +<listitem> +<para +>den SIN-Ausgang mit dem Eingang (inval) von ADSR</para> +</listitem> +<listitem> +<para +>den Ausgang (outvalue) von ADSR mit dem linken Strukturausgang</para> +</listitem +><listitem> +<para +>den ADSR-Ausgang (outvalue) mit dem rechten Strukturausgang</para> +</listitem> +</orderedlist> + +<para +>Setzen Sie die Parameter attack auf 0.1, decay auf 0.2, sustain auf 0.7 und release auf 0.1. </para> + +<para +>Weiterhin müssen wir daran denken, das die Instrumentenstruktur wissen muss, wenn der Spieler mit spielen fertig ist, da sonst der letzte Klang nicht beendet wird, auch wenn die letzte Taste losgelassen worden ist. Glücklicherweise weiß die ADSR-Hüllkurve (envelope), wann nichs mehr zu hören ist, da das Signal nach dem Loslassen der letzten Taste irgendwann auf Null reduziert wird. </para> + +<para +>Das wird erreicht, indem der Ausgang done auf 1 gesetzt wird. Verbinden Sie diesen Ausgang mit dem Ausgangskanal stopp. Damit wird die Struktur beendet, sobald dieser Ausgang auf 1 wechselt. </para> + +<para +>Benennen Sie die Struktur in Instrument_Anleitung um (durch <menuchoice +><guimenu +> Datei</guimenu +> <guimenuitem +>Struktur umbenennen</guimenuitem +></menuchoice +>). Speichern Sie die Struktur nun (der vorgegebene Name sollte jetzt Instrument_Anleitung sein).</para +><para +>Starten Sie nun artscontrol, wählen Sie <menuchoice +><guimenu +>Ansicht</guimenu +><guimenuitem +>Midi-Manager</guimenuitem +></menuchoice +> und wählen Sie<menuchoice +><guimenu +>Hinzufügen</guimenu +><guimenuitem +>aRts-Synthese Midi-Ausgabe</guimenuitem +></menuchoice +>. Hier sollten Sie in der Lage sein, ihr Instrument (Anleitung) auszuwählen. </para> + +<para +>Wenn Sie jetzt ein Terminal öffnen und <userinput +><command +>midisend</command +></userinput +> eintippen, sollte <command +>midisend</command +> und das Instrument im &arts; &MIDI;-Manager angezeigt werden. Wählen Sie beides aus und klicken Sie auf <guibutton +>Verbinden</guibutton +>. Damit sind die Vorbereitungen abgeschlossen. Nehmen Sie nun ihr Keyboard und beginnen Sie zu spielen (selbstverständlich nachdem Sie es mit dem Computer verbunden haben). </para> +</sect2> + +<sect2 id="suggestions"> +<title +>Hinweise</title> + +<para +>Sie sind nun in der Lage, &arts; zu verwenden. Hier sind noch einige Tipps, die den Umgang mit Strukturen verbessern können: </para> + +<itemizedlist> +<listitem> +<para +>Versuchen Sie andere Module anstelle von SIN. Wenn Sie eine TRI-Wellenform verwenden, werden Sie vermutlich feststellen, das diese Wellenform nicht besonders hübsch klingt. Hängen Sie einen SHELVE_CUTOFF-Filter an das TRI-Modul, um alle Frequenzen oberhalb einer bestimmten Grenzfrequenz (versuchen Sie etwa 1000 Hz oder besser noch die doppelte Eingabefrequenz +200 Hz oder einen ähnlichen Wert). </para> +</listitem> +<listitem> +<para +>Verwenden Sie mehrere Oszillatoren zusammen. Synth_XFADE kann zum kreuzweisen mixen (cross fade) von zwei Signalen verwendet werden, Synth_ADD zum Addieren von zwei Signalen. </para> +</listitem> +<listitem> +<para +>Verstimmen Sie die Oszillatoren geringfügig gegeneinander. Das erzeugt nette Schwebungen. </para> +</listitem> +<listitem> +<para +>Experimentieren Sie mit mehreren Hüllkurven (envelopes) gleichzeitig. </para> +</listitem> +<listitem> +<para +>Stellen Sie Instrumente zusammen, die verschiedene Signale auf den linken und rechten Ausgang legen. </para> +</listitem> +<listitem> +<para +>Verarbeiten Sie das Signal, das aus dem Downlink-Bus kommt, weiter. Sie können für einen Echo-Effekt das ursprüngliche Signal etwas verzögert dazumischen. </para> +</listitem> +<listitem> +<para +>Verwenden Sie die Lautstärkeeinstellung (die Stärke, mit der die Taste gedrückt worden ist). Ein besonderer Effekt entsteht, wenn der Lautstärkewert nicht nur die Ausgabelautstärke sondern auch den Klang des Instrumentes verändert (zum Beispiel die Grenzfrequenz). </para> +</listitem> +<listitem> +<para +>...</para> +</listitem> +</itemizedlist> + +<para +>Wenn Sie eine besondere Struktur konstruiert haben, schicken Sie sie an die &arts;-Internetseite. Sie kann dann der nächsten Version beigelegt werden. </para> +</sect2> + +</sect1> + +<sect1 id="artsbuilder-examples"> +<title +>Beispiele</title> + +<para +>Die Beispiele, mit denen &arts-builder; verteilt wird, können Sie unter <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Beispiel öffnen ...</guimenuitem +> </menuchoice +> finden. Einige befinden sich im angezeigten Verzeichnis, einige (die in der aktuellen Version aus irgendwelchen Gründen nicht funktionieren) befinden sich im todo-Verzeichnis. </para> +<para +>Die Beispiele können in mehrere Kategorien eingeteilt werden: </para> + +<itemizedlist> +<listitem> +<para +>Modulbeispiele demonstrieren jeweils eines der in arts enthaltenen Modules (<filename +>example_*.arts</filename +> benannt). Sie senden üblicherweise irgendwelche Ausgaben an die Soundkarte. </para> +</listitem> + +<listitem> +<para +>Instrumente (mit Namen <filename +>instrument_*.arts</filename +>) sind aus den grundlegenden arts-Modulen zusammengesetzt. Sie haben standardisierte Ein- und Ausgabekanäle, so dass sie mit dem &MIDI;-Manager aus &artscontrol; verwendet werden können. </para> +</listitem> + +<listitem> +<para +>Vorlagen ( mit Namen <filename +>template_*.arts</filename +>) zur Erstellung neuer Module. </para> +</listitem> + +<listitem> +<para +>Effekte (mit Namen <filename +>effect_*.arts</filename +>) können als Bausteine verwendet werden [momentan alle im todo-Verzeichnis] </para> +</listitem> + +<listitem> +<para +>Mixer-Elemente (mit Namen <filename +>mixer_element_*.arts</filename +>) können zur Erstellung von Mixern mit graphischen Kontrollelementen verwendet werden [momentan alle im todo-Verzeichnis ] </para> +</listitem> + +<listitem> +<para +>Verschiedene Module, die in keine der angegebenen Kategorien passen. </para> +</listitem> +</itemizedlist> + +<variablelist> +<title +>Detailierte Beschreibung der einzelnen Module:</title> +<varlistentry> +<term +><filename +>example_stereo_beep.arts</filename +></term> +<listitem> +<para +>Sendet einen 440Hz-Sinuston an den linken und einen 880Hz-Sinuston an den rechten Kanal der Soundkarte. Dieses Modul wird in der &arts;-Dokumentation erwähnt. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_sine.arts</filename +></term> +<listitem> +<para +>Erzeugt einen 440Hz-Sinuston. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_pulse.arts</filename +></term> +<listitem> +<para +>Erzeugt einen 440Hz-Impulston mit 20%-Arbeitswiederholung (duty cycle). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_softsaw.arts</filename +></term> +<listitem> +<para +>Erzeugt eine 440Hz-Sägezahnschwingung. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_square.arts</filename +></term> +<listitem> +<para +>Erzeugt eine 440Hz-Rechteckschwingung. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_tri.arts</filename +></term> +<listitem> +<para +>Erzeugt eine 440Hz-Dreieckschwingung. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_noise.arts</filename +></term> +<listitem> +<para +>Erzeugt weißen Lärm. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_dtmf1.arts</filename +></term> +<listitem> +<para +>Erzeugt einen Doppelton aus einer 697Hz- und 1209Hz-Sinusschwingung, die mit 0.5 skaliert und addiert werden. Es entsteht der DTMF-Ton für die Ziffer "1" einer Telefontastatur. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_atan_saturate.arts</filename +></term> +<listitem> +<para +>Eine Dreieckschwingung wird mit einem atan-Sättigungsfilter verändert. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_autopanner.arts</filename +></term> +<listitem> +<para +>Verwendet ein Autopan-Modul, um einen 400Hz-Sinuston mit einer Frequenz von 2 Hz zwischen dem linken und rechten Lautsprecher hin- und herzubewegen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_brickwall.arts</filename +></term> +<listitem> +<para +>Skaliert eine Sinusschwingung mit dem Faktor 5 und verändert sie mit einem brickwall-Begrenzer. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_bus.arts</filename +></term> +<listitem> +<para +>Vom Bus mit dem Namen <quote +>Bus</quote +> wird zum Bus <quote +>out_soundcard</quote +> eine Verbindung mit vertauschten Kanälen hergestellt. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_cdelay.arts</filename +></term> +<listitem> +<para +>Verbindet von einem Bus namens <quote +>Delay</quote +> zum rechten Ausgangskanal mit einer Verzögerung von 0.5 Sekunden (cdelay), während der linke Kanal unverändert bleibt. Mit &artscontrol; können Sie diesen Effekt mit einem Abspieler verbinden. Das Resultat ist hörenswert. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_delay.arts</filename +></term> +<listitem> +<para +>Das gleiche Beispiel wie <filename +>example_cdelay.arts</filename +>, mit dem Unterschied, dass der delay-Effekt anstelle von cdelay verwendet wird. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_capture_wav.arts</filename +></term> +<listitem> +<para +>Mit dem Modul Synth_CAPTURE_WAV wird ein 400Hz-Sinuston als wav-Datei gespeichert. Lassen Sie das Modul für 2 Sekunden laufen und untersuchen Sie die in <filename class="directory" +>/tmp</filename +> erzeugte Datei. Sie können Sie mit einem Spieler wie <application +>kaiman</application +> abspielen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_data.arts</filename +></term> +<listitem> +<para +>Mit einem Data-Modul wird ein konstanter Strom mit dem Wert <quote +>3</quote +> erzeugt und für die periodische Anzeige an ein Debug-Modul gesendet. Das Beispiel enthält weiterhin ein Nil-Modul, das demonstriert, wie man eine Struktur erzeugt, die gar nichts tut. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_adsr.arts</filename +></term> +<listitem> +<para +>Demonstriert, wie man mit dem Envelope-Adsr-Modul einen einfachen Instrumentenklang erzeugt, der durch eine Rechteckschwingung geschaltet wird. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_fm.arts</filename +></term> +<listitem> +<para +>Ein FM-Quellmodul erzeugt einen 440Hz-Sinuston, der dann mit 5 Hz frequenzmoduliert wird. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_freeverb.arts</filename +></term> +<listitem> +<para +>Verbindet den Freeverb-Effekt von einem Bus downlink zu einem Bus outlink. Sie können mit artscontrol diesen Effekt mit einem Spieler verbinden und sich das Resultat anhören. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_flanger.arts</filename +></term> +<listitem> +<para +>Implementiert einen einfachen Flanger-Effekt (scheint bisher nicht zu funktionieren). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_moog.arts</filename +></term> +<listitem> +<para +>Diese Struktur kombiniert zwei Kanäle von einem Bus, schickt das Signal durch einen Moog-VCF-Filter und das Ergebnis auf den out_soundcard-Bus. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_pitch_shift.arts</filename +></term> +<listitem> +<para +>Diese Struktur schickt den linken Kanal von Soundkartendaten durch einen Höhenverschiebungseffekt (pitch shift). Mit dem Speed-Parameter kann der Effekt modifiziert werden. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_rc.arts</filename +></term> +<listitem> +<para +>Diese Struktur sendet weißen Lärm durch einen RC-Filter und dann an die Soundkarte. Betrachten Sie das Ergebnis in der FFT-Anzeige von artscontrol, um den Unterschied zu ungefiltertem Lärm zu sehen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_sequence.arts</filename +></term> +<listitem> +<para +>Demonstriert die Verwendung des Sequencer-Moduls durch das Abspielen einer Notensequenz. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_shelve_cutoff.arts</filename +></term> +<listitem> +<para +>Diese Struktur schickt weißen Lärm durch einen Shelve-Cutoff-Filter und dann an die Soundkarte. Das Ergebnis können Sie in der FFT-Anzeige von artscontrol betrachten. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_equalizer.arts</filename +></term> +<listitem> +<para +>Demonstriert das Std_Equalizer-Modul. Es hebt die Höhen und Tiefen um 6dB an. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_tremolo.arts</filename +></term> +<listitem> +<para +>Demonstriert den Tremolo-Effekt. Der rechte und linke Kanal werden mit einem 10Hz-Tremolo moduliert. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_xfade.arts</filename +></term> +<listitem> +<para +>Dieses Beispiel mixt einen 440Hz- und einen 880Hz-Sinuston mit einem "cross fader". Verändern Sie die Prozentanzeige von -1 bis 1, um die Mischung der zwei Signale zu beeinflussen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_pscale.arts</filename +></term> +<listitem> +<para +>Demonstriert das Pscale-Modul (ich zweifle, dass dieses Beipiel aussagekräftig ist). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_play_wav.arts</filename +></term> +<listitem> +<para +>Illustriert das Play_Wave-Modul. Sie müssen den kompletten Pfad zur <literal role="extension" +>wav</literal +>-Datei als Parameter filename angeben. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>example_multi_add.arts</term> +<listitem> +<para +>Zeigt, wie das Multi_Add-Modul eine beliebige Anzahl Eingangssignale aufsummiert. Drei Eingänge mit den Werten 1,2 und 3 erzeugen den Ausgangswert 6. </para> +</listitem> +</varlistentry> +</variablelist> + +</sect1> +</chapter> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/detail.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/detail.docbook new file mode 100644 index 00000000000..69cd2931360 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/detail.docbook @@ -0,0 +1,1340 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.1.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="arts-in-detail"> +<title +>Details zu &arts;</title> + +<sect1 id="architecture"> +<title +>Architektur</title> + +<mediaobject +> <imageobject +> <imagedata fileref="arts-structure.png" format="PNG"/> </imageobject +> <textobject +><phrase +>Die Struktur von &arts;.</phrase +></textobject +> </mediaobject> +</sect1> + +<sect1 id="modules-ports"> +<title +>Module & Kanäle</title> + +<para +> &arts; beruht auf einem Synthesemodell, bei dem aus kleinen Modulen, die jedes für sich eine spezialisierte Aufgabe haben, komplexe Strukturen aufgebaut werden. Die Module haben normalerweise Eingänge, über die Signale und Parameter übergeben werden, und Ausgänge, an denen die Ergebnissignale anliegen. </para> + +<para +> Das Modul Synth_ADD zum Beispiel addiert die zwei Eingangssignal zu einem Summensignal, das als Ausgangssignal verfügbar ist. Die Stellen, mit denen die Ein-/Ausgangssignale verbunden werden heißen Kanäle (ports). </para> + +</sect1> + +<sect1 id="structures"> +<title +>Strukturen</title> + +<para +> Eine Struktur besteht aus mehreren verbundenen Modulen, bei denen einige Kanäle feste Parameter haben, andere untereinander verbunden sind während einige Kanäle vielleicht gar nicht verbunden sind. </para> + +<para +> &arts-builder; dient zur Beschreibung dieser Strukturen. Sie beschreiben, welche Module in welcher Weise verbunden werden sollen. Wenn Sie damit fertig sind, können Sie die Beschreibung speichern oder &arts; zu der Erzeugung der Struktur veranlassen (Struktur ausführen). </para> + +<para +> Als Ergebnis hören Sie wahrscheinlich einige Klänge, falls nichts schiefgegangen ist. </para> +</sect1> + +<!-- TODO + +<sect1 id="streams"> +<title +>Streams</title> +<para> +</para> +</sect1> + +--> + +<sect1 id="latency"> +<title +>Aussetzer</title> + +<sect2 id="what-islatency"> +<title +>Was bedeutet Verzögerung?</title> + +<para +> Angenommen Sie haben ein Programm mit Namen <quote +>Mausklick</quote +>, das ein <quote +>Klicken</quote +> von sich geben soll, wenn Sie eine Maustaste betätigen. Die Verzögerungszeit ist die Zeit zwischen dem Betätigen der Maustaste und dem Ertönen des Klicken. Die Einstellung der Verzögerungszeit besteht aus mehreren Verzögerungszeiten, die unterschiedliche Ursachen haben. </para> + +</sect2> + +<sect2 id="latenbcy-simple"> +<title +>Verzögerungszeit in einfachen Anwendungen</title> + +<para +> In dieser einfachen Anwendung werden an folgenden Stellen Verzögerungen verursacht: </para> + +<itemizedlist +> <listitem +> <para +> Zeit, die der Betriebssystemkern benötigt, um dem X11-Server den Mausklick mitzuteilen. </para +> </listitem +> <listitem +> <para +> Zeit, die der X11-Server benötigt, um der Anwendung den Mausklick mitzuteilen. </para +> </listitem +> <listitem +> <para +> Zeit, die die Anwendung benötigt, um aufgrund des Mausklicks einen Klick-Ton auszulösen. </para +> </listitem +> <listitem +> <para +> Zeit, die die Anwendung benötigt, um dem Soundserver den Befehl zum Klick-Ton zu geben. </para +> </listitem +> <listitem +> <para +> Zeit, die der Klick-Ton benötigt (den der Soundserver sofort in den Ausgabestrom einmischt), um den Datenpuffer zu passieren, bis er die Stelle erreicht, an der die Soundkarte gerade Daten wiedergibt. </para +> </listitem +> <listitem +> <para +> Zeit, die der Klick-Ton von den Lautsprechern bis zu Ihrem Ohr benötigt. </para +> </listitem +> </itemizedlist> + +<para +> Die ersten drei Verzögerungszeiten sind extern für &arts;. Sie sind wichtig, aber nicht Gegenstand dieser Dokumentation. Sie sollten sich dennoch dieser Verzögerungen bewusst sein, denn selbst wenn Sie alle anderen Verzögerungen sehr gering halten, erhalten Sie vielleicht dennoch nicht exakt die erwarteten Resultate. </para> + +<para +> Ein Spielbefehl an den Server besteht normalerweise aus einem &MCOP;-Funktionsaufruf. Es gibt Geschwindigkeitstests,die belegen, dass ein solcher Befehl auf einem Rechner bei der jetzigen Implementation etwa 9000 mal pro Sekunde ausgeführt werden kann. Ich denke, das meiste der Zeit wird Kernel-Overhead für die Umschaltung zwischen verschiedenen Anwendungen sein. Natürlich hängen diese Werte von den exakten Parametertypen des Aufrufs ab. Die Übergabe eines vollständigen Bildes in einem Aufruf dauert länger als die Übergabe eines einzigen Werte. Das Gleiche gilt für den Rückgabewert. Für normale Zeichenketten (wie der Dateiname der zu spielenden <literal role="extension" +>wav</literal +>-Datei) sollte das aber kein Problem darstellen. </para> + +<para +> Das bedeutet, diese Zeit kann mit 1/9000 Sekunde abgeschätzt werden. Das ist weniger als 0,15 ms. Sie werden sehen, das diese Zeitspanne unwichtig ist. </para> + +<para +> Die nächste Verzögerungszeit ist die Zeit vom Starten des Soundservers und der Ankunft dieses Beginns auf der Soundkarte. Der Server muss einen Puffer verwenden, damit man keine Aussetzer hört, wenn eine andere Anwendung wie der X11-Server oder das <quote +>Mausklick</quote +>-Programm aktiv sind. Das wird unter &Linux; verwirklicht, indem eine Anzahl Bruchstücke einer bestimmte Größe erzeugt werden. Der Server füllt die Bruchstücke und die Soundkarte spielt die Bruchstücke ab. </para> + +<para +> Angenommen es gibt drei Bruchstücke. Der Server füllt das Erste, die Soundkarte beginnt mit dem Abspielen. Der Server füllt das Zweite. Der Server füllt das Dritte. Der Server ist fertig, andere Anwendungen können nun aktiviert werden. </para> + +<para +> Nach dem ersten Bruchstück spielt die Soundkarte das Zweite ab und der Server füllt das erste Bruchstück wieder. Das geht immer so weiter. </para> + +<para +> Damit ergibt sich eine maximale Verzögerungszeit von (Anzahl der Bruchstücke)*(Größe eines Bruchstückes)/(Samplingrate * (Größe eines Samples)). Bei 44kHz Stereo und 7 Bruchstücken von je 1024 Byte Größe (die aktuellen Standardwerte von aRts) entspricht das einer Verzögerungszeit von 40 ms. </para> + +<para +> Diese Werte können Sie Ihren Anforderungen anpassen. Allerdings steigt die <acronym +>CPU</acronym +>-Belastung mit kleineren Verzögerungszeiten, da der Soundserver die Puffer häufiger und in kleineren Bruchstücken füllen muss. Es ist außerdem meistens unmöglich, bessere Werte zu erreichen, ohne das Aussetzer zu hören sind, es sei denn, sie versehen den Soundserver mit Echtzeit-Priorität. </para> + +<para +> Dennoch ist eine Einstellung von 3 Bruchstücken mit je 256 Bytes, die einer Verzögerung von 4,4 ms entsprechen, realistisch. Mit 4,4 ms Verzögerungszeit belastet &arts; die <acronym +>CPU</acronym +> im Ruhezustand mit 7,5%. Mit einer Verzögerung von 40 ms beträgt die Belastung etwa 3% (bei einem PII-350, diese Werte können abhängig von der Soundkarte, Kernel-Version und anderen Faktoren variieren). </para> + +<para +> Jetzt zu der Zeit, die der Klick-Ton von den Lautsprechern bis zum Ohr benötigt. Bei einer angenommenen Distanz von 2 Metern ergibt sich bei einer Schallgeschwindigkeit von 330 Meter pro Sekunde eine Verzögerung von etwa 6 ms. </para> + +</sect2> + +<sect2 id="latency-streaming"> +<title +>Verzögerungszeit in Streaming-Anwendungen</title> + +<para +> Streaming-Anwendungen produzieren ihre Klänge selbst. Angenommen, ein Spiel, das einen konstanten Strom von Samples erzeugt, soll nun für die Wiedergabe durch &arts; verwendet werden. Als Beispiel: Wenn ich eine Taste drücke, hüpft die Spielfigur und es ertönt ein Boing-Klang. </para> + +<para +> Als Erstes muss man wissen, wie &arts; Streaming realisiert. Der Ablauf ist ähnlich wie bei der Ausgabe auf einer Soundkarte. Das Spiel sendet einige Pakete mit Samples zum Soundserver. Angenommen, es sinc drei Pakete. Sobald der Soundserver das erste Paket wiedergegeben hat, schickt er eine Bestätigung zurück zum Spiel. </para> + +<para +> Das Spiel erzeugt ein neues Paket und schickt es zum Server. Währenddessen verarbeitet der Server das zweite Paket und so weiter. Die Verzögerungszeiten hier sind ähnlich wie bei dem einfachen Beispiel: </para> + +<itemizedlist +> <listitem +> <para +> Zeit, bis der Betriebssystemkern dem X11-Server den Tastendruck mitgeteilt hat. </para +> </listitem +> <listitem +> <para +> Zeit, bis der X11-Server dem Spiel den Tastendruck mitgeteilt hat. </para +> </listitem +> <listitem +> <para +> Zeit, bis das Spiel entschieden hat, das aufgrund des Tastendrucks ein Boing-Ton auszugeben ist. </para +> </listitem +> <listitem +> <para +> Zeit, bis das Paket mit dem Anfang des Boing-Tons den Soundserver erreicht hat. </para +> </listitem +> <listitem +> <para +> Zeit, bis der Boing-Ton (den der Soundserver sofort in die Ausgabe einmischt) den Datenpuffer passiert hat bis zu der Stelle, an der die Soundkarte gerade wiedergibt. </para +> </listitem +> <listitem +> <para +> Zeit, die der Boing-Ton von den Lautsprechern bis zum Ohr benötigt. </para +> </listitem +> </itemizedlist> + +<para +> Die externen Verzögerungen sind gehen wiederum über den Inhalt dieses Dokumentes hinaus. </para> + +<para +> Offensichtlich hängt die Streaming-Verzögerung von der Zeit ab, die alle Pakete benötigen, einmal wiedergegeben zu werden. Also ist diese Zeit (Anzahl der Pakete)*(Größe eines Paketes)/(Samplingrate * (Größe eines Samples)) </para> + +<para +> Wie man sieht, ist das die gleiche Formel, wie sie bei den Bruchstücken verwandt wird. Für Spiele sind solch geringer Verzögerungszeiten wie oben überflüssig. Eine realistische Festlegung für Spiekle wären 2046 Bytes pro Paket bei drei Paketen. Die resultierende Verzögerung ist dann etwa 35 ms. </para> + +<para +> Diese Berechnung basiert auf folgenden Annahmen: das Spiel rendert 25 Bilder pro Sekunde (für die Anzeige). Einen Verschiebung zwischen Ton und Film von einem Bild nimmt man nicht wahr. Daher ist eine Verzögerung von 1/25 Sekunde für Streaming akzeptabel, was wiederum bedeutet, das 40ms in Ordnung sind. </para> + +<para +> Außerdem werden die meisten Leute ihre Spiele nicht mit Echtzeit-Priorität spielen und daher ist die Gefahr von Aussetzern nicht zu vernachlässigen. Bei 3 Paketen je 256 Bytes ist Streaming möglich (nach eigenen Tests) - es verbraucht aber eine Menge <acronym +>CPU</acronym +>-Zeit. </para> + +<para +> Für die Serververzögerungszeiten können Sie genau wie oben rechnen. </para> + +</sect2> + +<sect2 id="cpu-usage"> +<title +>Einige Überlegungen zu <acronym +>CPU</acronym +>-Zeit</title> + +<para +> Es gibt eine Menge Faktoren, die in komplexen Situationen mit einigen Streaming-Anwendungen und einigen Anderen sowie einigen Plugins auf dem Server einen Einfluß auf die <acronym +>CPU</acronym +>-Zeit haben. Um einige zu nennen: </para> + +<itemizedlist +> <listitem +> <para +> <acronym +>CPU</acronym +>-Zeit für die notwendigen Berechnungen. </para +> </listitem +> <listitem +> <para +> &arts; interner Scheduler-Aufwand - wie &arts; entscheidet, wann welches Modul was berechnen soll. </para +> </listitem +> <listitem +> <para +> Aufwand zur Konvertierung von Ganzzahlen in Kommazahlen. </para +> </listitem +> <listitem +> <para +> &MCOP;-Protokoll-Aufwand. </para +> </listitem +> <listitem +> <para +> Kernel: Prozeß-/Kontextumschaltung. </para +> </listitem +> <listitem +> <para +> Kernel: Kommunikationsaufwand. </para +> </listitem +> </itemizedlist> + +<para +> Für die <acronym +>CPU</acronym +>-Berechnungszeit bei zwei gleichzeitig abgespielten Datenströmen muss man Additionen durchführen. Falls man einen Filter verwendet, sind einige weitere Berechnungen notwendig. Ein einfaches Beispiel mit zwei Strömen mit vier <acronym +>CPU</acronym +>-Zyklen pro Addition führen auf einem 350MHz-Prozessor zu 44100*2*4/350000000 = 0,1% <acronym +>CPU</acronym +>-Auslastung. </para> + +<para +> &arts; internes Scheduling: &arts; muss bestimmen, welches Plugin wann was berechnet. Das benötigt Zeit. Wenn man Genaueres wissen will, sollte man einen Profiler zu Rate ziehen. Generell lässt sich Folgendes sagen: je weniger Wert man auf Echtzeit legt (also je größer die zu berechnenden Blöcke sind) um so wenig Scheduling Zeit wird benötigt. Bei mehr als 128 Samples in einem Stück (also einer Bruchstückgröße von 512 Bytes) ist der Scheduling-Aufwand wahrscheinlich nicht einmal nennenswert. </para> + +<para +> Aufwand zur Konvertierung von Ganzzahlen in Kommazahlen: &arts; verwendet intern Kommazahlen als Datenformat. Sie sind einfach zu verarbeiten und auf zeitgemäßen Prozessoren kaum langsamer als Ganzzahlen. Wenn aber Programme ihre Daten nicht in Kommazahlen abspielen (wie ein Spiel, das seine Känge über &arts; ausgibt), müssen diese Daten konvertiert werden. Das Gleiche gilt für die Ausgabe auf einer Soundkarte. Soundkarten benötigen Ganzzahlen, also muss eine Konvertierung durchgeführt werden. </para> + +<para +> Die folgenden Zahlen gehören zu einem Celeron, ungefähre ticks pro Sample, mit -O2 +egcs 2.91.66 (berechnet von Eugene Smith <email +>hamster@null.ru</email +>). Diese Zahlen sind naturgemäß sehr prozessorabhängig. </para> + +<programlisting> +convert_mono_8_float: 14 +convert_stereo_i8_2float: 28 +convert_mono_16le_float: 40 +interpolate_mono_16le_float: 200 +convert_stereo_i16le_2float: 80 +convert_mono_float_16le: 80 +</programlisting> + +<para +> Das bedeutet 1% <acronym +>CPU</acronym +>-Zeit für die Konvertierung und 5% für die Interpolation auf diesem 350 MHz-Prozessor. </para> + +<para +> &MCOP; Protokoll-Aufwand: &MCOP; verträgt ungefähr 9000 Aufrufe pro Sekunde. Das hat wenige mit &MCOP; als mit den zwei Kernelgründen zu tun, die weiter unten beschrieben werden. Dennoch gibt das einen Anhaltspunkt für die Berechnung der Kosten von Streaming. </para> + +<para +> Jedes übertragene Datenpaket erfordert einen &MCOP;-Aufruf. Natürlich ist das nur ein Richtwert, da große Pakete langsamer als 9000 Pakete/s sind. </para> + +<para +> Angenommen man verwendet als Paketgröße 1024 Bytes. Für einen Stream mit 44kHz Stereo muss man also 44100*4/1024 = 172 Pakete pro Sekunde übertragen. Weiter angenommen, 9000 Pakete pro Sekunde entspricht einer <acronym +>CPU</acronym +>-Auslastung von 100%, dann erhält man (172*100)/9000 = 2% <acronym +>CPU</acronym +>-Auslastung bei einem Streaming mit 1024 Bytes pro Paket. </para> + +<para +> Das sind nur Näherungen. Sie zeigen aber deutlich, dass man viel besser dran ist (wenn man die Verzögerungszeit tolerieren kann) mit einer Paketgröße von 4096 Bytes. Wir können eine kompakte Rechnung durchführen, wenn wir die Paketgröße für 100% <acronym +>CPU</acronym +>-Auslastung berechnen mit 44100*4/9000 = 19,6 Samples; daraus erhalten wir folgende Formel: </para> + +<para +> Streaming <acronym +>CPU</acronym +>-Auslastung in Prozent = 1960/(Paketgröße) </para> + +<para +> das ergibt 0,5% <acronym +>CPU</acronym +>-Auslastung bei Streaming mit einer Paketgröße von 4096 Bytes. </para> + +<para +> Kernel Prozeß-/Kontextumschaltung: dieser Aufwand ist ein Teil des &MCOP;-Protokolls. Die Umschaltung zwischen zwei Prozessen benötigt Zeit. Es wird der Speicher neu aufgeteilt, der Cache wird ungültig, und vieles mehr (falls ein Kernel-Experte dieses liest - teilen Sie mir bitte die genauen Gründe mit). Das bedeutet: es benötigt Zeit. </para> + +<para +> Ich weiß nicht wie viele Kontextwechsel Linux verträgt, aber sicher nur eine endliche Zahl. Daher nehme ich an, das ein erheblicher Teil des &MCOP; Protokollaufwandes durch Kontextumschaltung zu Stande kommt. Ich führte einige Tests mit &MCOP;-Kommunikation innerhalb eines Prozesses durch. Sie war wesentlich schneller (etwa viermal so schnell). </para> + +<para +> Kernel: Kommunikationsaufwand: Das ist ebenfalls ein Bestandteil des &MCOP; Protokollaufwandes. Die Datenübertragung zwischen Prozessen wird momentan mittels Sockets durchgeführt. Das ist praktisch, da die üblichen select()-Methoden verwendet werden können, um die Ankunft einer Nachricht zu überprüfen. Das kann leicht mit anderen Ein-/Ausgabequellen wie Audio Ein-/Ausgabe, X11-Server-Kommunikation und einigem Anderen kombiniert werden. </para> + +<para +> Diese Lese- und Schreibaufrufe kosten mit Sicherheit Prozessorzeit. Kleine Aufrufe (um ein Midi-Ereignis zu übertragen) sind vermutlich nicht so schlimm, große Aufrufe (z.B. um ein Videobild mit einigen Megabytes zu übertragen) stellen sicherlich ein Problem dar. </para> + +<para +> In &MCOP; sollte daher möglichst gemeinsam genutzter Speicher verwendet werden. Das sollte aber keine Änderungen für die Anwendungsprogrammierer mit sich bringen. </para> + +<para +> Durch einen Profiler kann man herausbekommen, in welchem Maße genau heutiges Audio Streaming unter der Nichtverwendung von gemeinsam genutztem Speicher leidet. Da Audio Streaming mit &artsd; und <application +>artscat</application +> mit 6% <acronym +>CPU</acronym +>-Auslastung (Wiedergabe von mp3) durchgeführt werden kann (und 5% für den mp3-Dekoder), kann es nicht so schlimm sein. Das enthält alles einschließlich der notwendigen Berechnungen und dem Socket-Aufwand, daher vermute ich, durch gemeinsam genutzten Speicher könnten vielleicht 1% <acronym +>CPU</acronym +>-Auslastung gespart werden. </para> + +</sect2> + +<sect2 id="hard-numbers"> +<title +>Einige genaue Zahlen</title> + +<para +> Diese Zahlen wurden mit der aktuellen CVS-Version ermittelt. Außerdem wollte ich Grenzfälle testen, also sind das Fälle, die in normalen Anwendungen nicht auftreten sollten. </para> + +<para +> Ich habe ein Programm namens streamsound geschrieben, das Streaming Daten an &arts; sendet. Die Anwendung läuft hier mit Echtzeit-Priorität (ohne Probleme) und einem kleinen Plugin (für Lauststärkeskalierung und Clipping) auf seiten des Servers: </para> + +<programlisting> + 4974 stefan 20 0 2360 2360 1784 S 0 17.7 1.8 0:21 artsd + 5016 stefan 20 0 2208 2208 1684 S 0 7.2 1.7 0:02 streamsound + 5002 stefan 20 0 2208 2208 1684 S 0 6.8 1.7 0:07 streamsound + 4997 stefan 20 0 2208 2208 1684 S 0 6.6 1.7 0:07 streamsound +</programlisting> + +<para +> Das Streaming wird jeweils mit 3 Bruchstücken je 1024 Bytes (18 ms) durchgeführt. Drei Programme laufen gleichzeitig. Das scheint ein bisschen zu viel zu sein; mit einem Profiler kann man versuchen, den Aufwand zu verbessern. </para> + +<para +> Das ist ein nicht realistisches Testbeispiel. Als weiteren Test wurde versucht, die minimal mögliche Verzögerungszeit herauszufinden. Resultat: man kann Streaming ohne Unterbrechungen mit einem Anwendungsprogramm bei zwei Bruchstücken je 128 Bytes zwischen &arts; und der Soundkarte sowie zwischen der Anwendung und &arts; durchführen. Das entspricht einer maximalen Verzögerung von 128*4/44100*4 = 3 ms, wobei 1,5 ms von der Soundkarte und 1,5 ms durch die Kommunikation mit &arts; entstehen. Beide Anwendungen benötigen Echtzeit-Priorität. </para> + +<para +> Das benötigt allerdings einen erheblichen Anteil der <acronym +>CPU</acronym +>. Das Beispiel liegt bei etwa 45% auf meinem P-II/350. Es wird ein Klicken hörbar, wenn man Fenster in X11 bewegt oder Festplattenaktivität verursacht. Das hängt mit dem Kernel zusammen. Das Problem ist, das zwei Echtzeitanwendungen einen erheblichen Aufwand verursachen, mehr noch, wenn Sie auch noch miteinander kommunizieren. </para> + +<para +> Schließlich ein realistischeres Beispiel. Es besteht aus &arts; mit artsd und einem artscat (ein Streaming Programm) bei 16 Bruchstücken mit je 4096 Bytes: </para> + +<programlisting> + 5548 stefan 12 0 2364 2364 1752 R 0 4.9 1.8 0:03 artsd + 5554 stefan 3 0 752 752 572 R 0 0.7 0.5 0:00 top + 5550 stefan 2 0 2280 2280 1696 S 0 0.5 1.7 0:00 artscat +</programlisting> + +</sect2> +</sect1> + +<!-- TODO + +<sect1 id="dynamic-instantiation"> +<title +>Dynamic Instantiation</title> +<para> +</para> +</sect1> + +--> + +<sect1 id="busses"> +<title +>Busse</title> + +<para +> Busse sind dynamisch erzeugte Verbindungen zum Transport von Audiosignalen. Grundlegend werden alle Signale von Uplinks addiert und an die Downlinks weitergeleitet. </para> + +<para +> Busse existieren momentan nur in Stereo. Wenn Sie Mono-Daten transportieren wollen, senden Sie sie über einen Kanal und setzen Sie den anderen auf Null. Zur Verwendung erstellen Sie einen oder mehrere Synth_BUS_UPLINK-Module und benennen Sie sie mit dem Busnamen, auf dem Sie senden sollen (z.B. <quote +>audio</quote +> oder <quote +>drums</quote +>). Dann senden Sie die Daten an diese Uplinks. </para> + +<para +> Auf der anderen Seite benötigen Sie einen oder mehrere Synth_BUS_DOWNLINK-Module, denen Sie die gleichen Busnamen geben (also <quote +>audio</quote +> oder <quote +>drums</quote +> ... gleiche Busnamen werden verbunden). Über diese Busenden erscheinen die gesendeten Signale wieder in einer Struktur. </para> + +<para +> Die Uplinks und Downlinks können zu unterschiedlichen Strukturen gehören. Sie können sogar zwei Instanzen von &arts-builder; verwenden und in einer davon einen Uplink und in der Anderen den passenden Downlink haben. </para> + +<para +> Eine besondere Eigenschaft ist die Dynamik dieser Verbindungen. Teile können sich jederzeit ein- oder ausklinken; das sollte kein Klicken oder andere Geräusche verursachen. </para> + +<para +> Natürlich sollte kein Teil ausgeklinkt werden, während sein Signalpegel höher als Null ist, da sonst natürlich ein Klicken zu hören sein wird. </para> +</sect1> + +<!-- TODO +<sect1 id="network-ransparency"> +<title +>Network Transparency</title> +<para> +</para> +</sect1> + +<sect1 id="security"> +<title +>Security</title> +<para> +</para> +</sect1> + + +<sect1 id="effects"> +<title +>Effects and Effect Stacks</title> +<para> +</para> +</sect1> + +--> +<sect1 id="trader"> +<title +>Trader</title> + +<para +> &arts;/&MCOP; basiert sehr auf der Aufteilung von Aufgaben in kleine Komponenten. Das System wird dadurch sehr flexibel, da man das System auf einfache Weise durch das Hinzufügen neuer Komponenten, die neue Effekte, Dateiformate, Oszillatoren, GUI-Elemente, ... bereitstellen, erweitert werden kann. Da beinahe alles als Komponente programmiert ist, kann beinahe alles einfach erweitert werden, ohne die existierenden Quellen zu verändern. Neue Komponenten, die das System erweitern, werden einfach dynamisch geladen. </para> + +<para +> Für einen reibungslosen Ablauf sind zwei Dinge erforderlich: </para> + +<itemizedlist +> <listitem +> <para +> Komponenten müssen sich bekannt machen - sie müssen ihre Funktionen beschreiben, damit andere Programme sie verwenden können. </para +> </listitem +> <listitem +> <para +> Anwendungen müssen aktiv nach verwendbaren Komponenten suchen, anstatt immer die gleichen DInge für eine Aufgabe zu verwenden. </para +> </listitem +> </itemizedlist> + +<para +> Die Kombination davon: Komponenten, die sagen: <quote +>Hier bin ich, verwende mich</quote +>, und Anwendungen (oder, wenn man so will, andere Komponenten), die nach verwendbaren Komponenten suchen, um eine Aufgabe zu erledigen, nennt man Handel. </para> + +<para +> In &arts; beschreiben Komponenten sich selbst, indem sie Werte festlegen, die sie als Eigenschaften <quote +>unterstützen</quote +>. Eine typische Eigenschaft einer Komponente zum Laden einer Datei könnte die Dateinamenerweiterung sein, die sie verarbeiten kann. Typische Werte könnten <literal role="extension" +>wav</literal +>, <literal role="extension" +>aiff</literal +> oder <literal role="extension" +>mp3</literal +> sein. </para> + +<para +> Jede Komponente kann viele verschiedene Werte für eine Eigenschaft anbieten. Eine einzige Komponente kann somit sowohl das Einlesen von <literal role="extension" +>wav</literal +> als auch <literal role="extension" +>aiff</literal +>-Dateien anbieten, indem sie diese Werte für die Eigenschaft <quote +>Extension</quote +> angibt. </para> + +<para +> Um das durchzuführen, muss die Komponente eine <literal role="extension" +>.mcopclass</literal +>-Datei an geeigneter Stelle platzieren, in der sie die unterstützten Eigenschaften festlegt. Eine solche Datei könnte folgendermaßen aussehen (und würde in <filename +><replaceable +>componentdir</replaceable +>/Arts/WavPlayObject.mcopclass</filename +> installiert): </para> + +<programlisting> +Interface=Arts::WavPlayObject,Arts::PlayObject,Arts::SynthModule,Arts::Object +Author="Stefan Westerfeld <stefan@space.twc.de>" +URL="http://www.arts-project.org" +Extension=wav,aiff +MimeType=audio/x-wav,audio/x-aiff +</programlisting> + +<para +> It is important that the filename of the <literal role="extension" +>.mcopclass</literal +>-file also says what the interface of the component is called like. The trader doesn't look at the contents at all, if the file (like here) is called <filename +>Arts/WavPlayObject.mcopclass</filename +>, the component interface is called <interfacename +>Arts::WavPlayObject</interfacename +> (modules map to directories). </para> + +<para +> To look for components, there are two interfaces (which are defined in <filename +>core.idl</filename +>, so you have them in every application), called <interfacename +>Arts::TraderQuery</interfacename +> and <interfacename +>Arts::TraderOffer</interfacename +>. You to go on a <quote +>shopping tour</quote +> for components like this: </para> + +<orderedlist +> <listitem +> <para +> Create a query object: </para +> <programlisting> + Arts::TraderQuery query; +</programlisting +> </listitem +> <listitem +> <para +> Specify what you want. As you saw above, components describe themselves using properties, for which they offer certain values. So specifying what you want is done by selecting components that support a certain value for a property. This is done using the supports method of a TraderQuery: </para +> <programlisting> + query.supports("Interface","Arts::PlayObject"); + query.supports("Extension","wav"); +</programlisting +> </listitem +> <listitem +> <para +> Finally, perform the query using the query method. Then, you'll (hopefully) get some offers: </para +> <programlisting> + vector<Arts::TraderOffer> *offers = query.query(); +</programlisting +> </listitem +> <listitem +> <para +> Now you can examine what you found. Important is the interfaceName method of TraderOffer, which will tell you the name of the component, that matched the query. You can also find out further properties by getProperty. The following code will simply iterate through all components, print their interface names (which could be used for creation), and delete the results of the query again: </para +> <programlisting> + vector<Arts::TraderOffer>::iterator i; + for(i = offers->begin(); i != offers->end(); i++) + cout << i->interfaceName() << endl; + delete offers; +</programlisting +> </listitem +> </orderedlist> + +<para +> For this kind of trading service to be useful, it is important to somehow agree on what kinds of properties components should usually define. It is essential that more or less all components in a certain area use the same set of properties to describe themselves (and the same set of values where applicable), so that applications (or other components) will be able to find them. </para> + +<para +> Author (type string, optional): This can be used to ultimately let the world know that you wrote something. You can write anything you like in here, e-mail adress is of course helpful. </para> + +<para +> Buildable (type boolean, recommended): This indicates whether the component is usable with <acronym +>RAD</acronym +> tools (such as &arts-builder;) which use components by assigning properties and connecting ports. It is recommended to set this value to true for almost any signal processing component (such as filters, effects, oscillators, ...), and for all other things which can be used in <acronym +>RAD</acronym +> like fashion, but not for internal stuff like for instance <interfacename +>Arts::InterfaceRepo</interfacename +>. </para> + +<para +> Extension (type string, used where relevant): Everything dealing with files should consider using this. You should put the lowercase version of the file extension without the <quote +>.</quote +> here, so something like <userinput +>wav</userinput +> should be fine. </para> + +<para +> Interface (type string, required): This should include the full list of (useful) interfaces your components supports, probably including <interfacename +>Arts::Object</interfacename +> and if applicable <interfacename +>Arts::SynthModule</interfacename +>. </para> + +<para +> Language (type string, recommended): If you want your component to be dynamically loaded, you need to specify the language here. Currently, the only allowed value is <userinput +>C++</userinput +>, which means the component was written using the normal C++ <acronym +>API</acronym +>. If you do so, you'll also need to set the <quote +>Library</quote +> property below. </para> + +<para +> Library (type string, used where relevant): Components written in C++ can be dynamically loaded. To do so, you have to compile them into a dynamically loadable libtool (<literal role="extension" +>.la</literal +>) module. Here, you can specify the name of the <literal role="extension" +>.la</literal +>-File that contains your component. Remember to use REGISTER_IMPLEMENTATION (as always). </para> + +<para +> MimeType (type string, used where relevant): Everything dealing with files should consider using this. You should put the lowercase version of the standard mimetype here, for instance <userinput +>audio/x-wav</userinput +>. </para> + +<para +> &URL; (type string, optional): If you like to let people know where they can find a new version of the component (or a homepage or anything), you can do it here. This should be standard &HTTP; or &FTP; &URL;. </para> + +</sect1> + +<!-- TODO +<sect1 id="midi-synthesis"> +<title +><acronym +>MIDI</acronym +> Synthesis</title> +<para> +</para> +</sect1> + +<sect1 id="instruments"> +<title +>Instruments</title> +<para> +</para> +</sect1> + +<sect1 id="session-management"> +<title +>Session Management</title> +<para> +</para> +</sect1> + +<sect1 id="full-duplex"> +<title +>Full duplex Audio</title> +<para> +</para> +</sect1> +--> + +<sect1 id="namespaces"> +<title +>Namespaces in &arts;</title> + +<sect2 id="namespaces-intro"> +<title +>Einleitung</title> + +<para +> Each namespace declaration corresponds to a <quote +>module</quote +> declaration in the &MCOP; &IDL;. </para> + +<programlisting> +// mcop idl + +module M { + interface A + { + } +}; + +interface B; +</programlisting> + +<para +> In this case, the generated C++ code for the &IDL; snippet would look like this: </para> + +<programlisting> +// C++ header + +namespace M { + /* declaration of A_base/A_skel/A_stub and similar */ + class A { // Smartwrapped reference class + /* [...] */ + }; +} + +/* declaration of B_base/B_skel/B_stub and similar */ +class B { + /* [...] */ +}; +</programlisting> + +<para +> So when referring the classes from the above example in your C++ code, you would have to write <classname +>M::A</classname +>, but only B. However, you can of course use <quote +>using M</quote +> somewhere - like with any namespace in C++. </para> + +</sect2> + +<sect2 id="namespaces-how"> +<title +>How &arts; uses namespaces</title> + +<para +> There is one global namespace called <quote +>Arts</quote +>, which all programs and libraries that belong to &arts; itself use to put their declarations in. This means, that when writing C++ code that depends on &arts;, you normally have to prefix every class you use with <classname +>Arts::</classname +>, like this: </para> + +<programlisting> +int main(int argc, char **argv) +{ + Arts::Dispatcher dispatcher; + Arts::SimpleSoundServer server(Arts::Reference("global:Arts_SimpleSoundServer")); + + server.play("/var/foo/somefile.wav"); +</programlisting> + +<para +> The other alternative is to write a using once, like this: </para> + +<programlisting> +using namespace Arts; + +int main(int argc, char **argv) +{ + Dispatcher dispatcher; + SimpleSoundServer server(Reference("global:Arts_SimpleSoundServer")); + + server.play("/var/foo/somefile.wav"); + [...] +</programlisting> + +<para +> In &IDL; files, you don't exactly have a choice. If you are writing code that belongs to &arts; itself, you'll have to put it into module &arts;. </para> + +<programlisting> +// IDL File for aRts code: +#include <artsflow.idl> +module Arts { // put it into the Arts namespace + interface Synth_TWEAK : SynthModule + { + in audio stream invalue; + out audio stream outvalue; + attribute float tweakFactor; + }; +}; +</programlisting> + +<para +> If you write code that doesn't belong to &arts; itself, you should not put it into the <quote +>Arts</quote +> namespace. However, you can make an own namespace if you like. In any case, you'll have to prefix classes you use from &arts;. </para> + +<programlisting> +// IDL File for code which doesn't belong to aRts: +#include <artsflow.idl> + +// either write without module declaration, then the generated classes will +// not use a namespace: +interface Synth_TWEAK2 : Arts::SynthModule +{ + in audio stream invalue; + out audio stream outvalue; + attribute float tweakFactor; +}; + +// however, you can also choose your own namespace, if you like, so if you +// write an application "PowerRadio", you could for instance do it like this: +module PowerRadio { + struct Station { + string name; + float frequency; + }; + + interface Tuner : Arts::SynthModule { + attribute Station station; // no need to prefix Station, same module + out audio stream left, right; + }; +}; +</programlisting> + +</sect2> + +<sect2 id="namespaces-implementation"> +<title +>Internals: How the Implementation Works</title> + +<para +> Often, in interfaces, casts, method signatures and similar, &MCOP; needs to refer to names of types or interfaces. These are represented as string in the common &MCOP; datastructures, while the namespace is always fully represented in the C++ style. This means the strings would contain <quote +>M::A</quote +> and <quote +>B</quote +>, following the example above. </para> + +<para +> Note this even applies if inside the &IDL; text the namespace qualifiers were not given, since the context made clear which namespace the interface <interfacename +>A</interfacename +> was meant to be used in. </para> + +</sect2> +</sect1> + +<sect1 id="threads"> +<title +>Threads in &arts;</title> + +<sect2 id="threads-basics"> +<title +>Basics</title> + +<para +> Using threads isn't possible on all platforms. This is why &arts; was originally written without using threading at all. For almost all problems, for each threaded solution to the problem, there is a non-threaded solution that does the same. </para> + +<para +> For instance, instead of putting audio output in a seperate thread, and make it blocking, &arts; uses non-blocking audio output, and figures out when to write the next chunk of data using <function +>select()</function +>. </para> + +<para +> However, &arts; (in very recent versions) at least provides support for people who do want to implement their objects using threads. For instance, if you already have code for an <literal role="extension" +>mp3</literal +> player, and the code expects the <literal role="extension" +>mp3</literal +> decoder to run in a seperate thread, it's usally the easiest thing to do to keep this design. </para> + +<para +> The &arts;/&MCOP; implementation is built along sharing state between seperate objects in obvious and non-obvious ways. A small list of shared state includes: </para> + +<itemizedlist +> <listitem +><para +> The Dispatcher object which does &MCOP; communication. </para +> </listitem +> <listitem +> <para +> The Reference counting (Smartwrappers). </para +> </listitem +> <listitem +> <para +> The IOManager which does timer and fd watches. </para +> </listitem +> <listitem +> <para +> The ObjectManager which creates objects and dynamically loads plugins. </para +> </listitem +> <listitem +> <para +> The FlowSystem which calls calculateBlock in the appropriate situations. </para +> </listitem +> </itemizedlist> + +<para +> All of the above objects don't expect to be used concurrently (&dh; called from seperate threads at the same time). Generally there are two ways of solving this: </para> + +<itemizedlist +> <listitem +> <para +> Require the caller of any functions on this objects to acquire a lock before using them. </para +> </listitem +> <listitem +> <para +> Making these objects really threadsafe and/or create per-thread instances of them. </para +> </listitem +> </itemizedlist> + +<para +> &arts; follows the first approach: you will need a lock whenever you talk to any of these objects. The second approach is harder to do. A hack which tries to achieve this is available at <ulink url="http://space.twc.de/~stefan/kde/download/arts-mt.tar.gz" +> http://space.twc.de/~stefan/kde/download/arts-mt.tar.gz</ulink +>, but for the current point in time, a minimalistic approach will probably work better, and cause less problems with existing applications. </para> + +</sect2> +<sect2 id="threads-locking"> +<title +>When/how to acquire the lock?</title> + +<para +> You can get/release the lock with the two functions: </para> + +<itemizedlist +> <listitem +> <para +> <ulink url="http://space.twc.de/~stefan/kde/arts-mcop-doc/arts-reference/headers/Arts__Dispatcher.html#lock" +><function +>Arts::Dispatcher::lock()</function +></ulink +> </para +> </listitem +> <listitem +> <para +> <ulink url="http://space.twc.de/~stefan/kde/arts-mcop-doc/arts-reference/headers/Arts__Dispatcher.html#unlock" +><function +>Arts::Dispatcher::unlock()</function +></ulink +> </para +> </listitem +> </itemizedlist> + +<para +> Generally, you don't need to acquire the lock (and you shouldn't try to do so), if it is already held. A list of conditions when this is the case is: </para> + +<itemizedlist +> <listitem +> <para +> You receive a callback from the IOManager (timer or fd). </para +> </listitem +> <listitem +> <para +> You get call due to some &MCOP; request. </para +> </listitem +> <listitem +> <para +> You are called from the NotificationManager. </para +> </listitem +> <listitem +> <para +> You are called from the FlowSystem (calculateBlock) </para +> </listitem +> </itemizedlist> + +<para +> There are also some exceptions of functions. which you can only call in the main thread, and for that reason you will never need a lock to call them: </para> + +<itemizedlist +> <listitem +> <para +> Constructor/destructor of Dispatcher/IOManager. </para +> </listitem +> <listitem +> <para +> <methodname +>Dispatcher::run()</methodname +> / <methodname +>IOManager::run()</methodname +> </para +> </listitem +> <listitem +> <para +><methodname +>IOManager::processOneEvent()</methodname +></para +> </listitem +> </itemizedlist> + +<para +> But that is it. For everything else that is somehow related to &arts;, you will need to get the lock, and release it again when done. Always. Here is a simple example: </para> + +<programlisting> +class SuspendTimeThread : Arts::Thread { +public: + void run() { + /* + * you need this lock because: + * - constructing a reference needs a lock (as global: will go to + * the object manager, which might in turn need the GlobalComm + * object to look up where to connect to) + * - assigning a smartwrapper needs a lock + * - constructing an object from reference needs a lock (because it + * might need to connect a server) + */ + Arts::Dispatcher::lock(); + Arts::SoundServer server = Arts::Reference("global:Arts_SoundServer"); + Arts::Dispatcher::unlock(); + + for(;;) { /* + * you need a lock here, because + * - dereferencing a smartwrapper needs a lock (because it might + * do lazy creation) + * - doing an MCOP invocation needs a lock + */ + Arts::Dispatcher::lock(); + long seconds = server.secondsUntilSuspend(); + Arts::Dispatcher::unlock(); + + printf("seconds until suspend = %d",seconds); + sleep(1); + } + } +} +</programlisting> + + +</sect2> + +<sect2 id="threads-classes"> +<title +>Threading related classes</title> + +<para +> The following threading related classes are currently available: </para> + +<itemizedlist +> <listitem +> <para +> <ulink url="http://www.arts-project.org/doc/headers/Arts__Thread.html" +><classname +> Arts::Thread</classname +></ulink +> - which encapsulates a thread. </para +> </listitem +> <listitem +> <para +> <ulink url="http://www.arts-project.org/doc/headers/Arts__Mutex.html" +> <classname +>Arts::Mutex</classname +></ulink +> - which encapsulates a mutex. </para +> </listitem +> <listitem +> <para +> <ulink url="http://www.arts-project.org/doc/headers/Arts__ThreadCondition.html" +> <classname +>Arts::ThreadCondition</classname +></ulink +> - which provides support to wake up threads which are waiting for a certain condition to become true. </para +> </listitem +> <listitem +> <para +> <ulink url="http://www.arts-project.org/doc/headers/Arts__SystemThreads.html" +><classname +>Arts::SystemThreads</classname +></ulink +> - which encapsulates the operating system threading layer (which offers a few helpful functions to application programmers). </para +> </listitem +> </itemizedlist> + +<para +> See the links for documentation. </para> + +</sect2> +</sect1> + +<sect1 id="references-errors"> +<title +>References and Error Handling</title> + +<para +> &MCOP; references are one of the most central concepts in &MCOP; programming. This section will try to describe how exactly references are used, and will especially also try to cover cases of failure (server crashes). </para> + +<sect2 id="references-properties"> +<title +>Basic properties of references</title> + +<itemizedlist +> <listitem +> <para +> An &MCOP; reference is not an object, but a reference to an object: Even though the following declaration <programlisting> + Arts::Synth_PLAY p; +</programlisting +> looks like a definition of an object, it only declares a reference to an object. As C++ programmer, you might also think of it as Synth_PLAY *, a kind of pointer to a Synth_PLAY object. This especially means, that p can be the same thing as a NULL pointer. </para +> </listitem +> <listitem +> <para +> You can create a NULL reference by assigning it explicitly </para +> <programlisting> + Arts::Synth_PLAY p = Arts::Synth_PLAY::null(); +</programlisting +> </listitem +> <listitem +> <para +> Invoking things on a NULL reference leads to a core dump </para +> <programlisting> + Arts::Synth_PLAY p = Arts::Synth_PLAY::null(); + string s = p.toString(); +</programlisting +> <para +> will lead to a core dump. Comparing this to a pointer, it is essentially the same as <programlisting> + QWindow* w = 0; + w->show(); +</programlisting +> which every C++ programmer would know to avoid. </para +> </listitem +> <listitem +> <para +> Uninitialized objects try to lazy-create themselves upon first use </para +> <programlisting> + Arts::Synth_PLAY p; + string s = p.toString(); +</programlisting +> <para +> is something different than dereferencing a NULL pointer. You didn't tell the object at all what it is, and now you try to use it. The guess here is that you want to have a new local instance of a Arts::Synth_PLAY object. Of course you might have wanted something else (like creating the object somewhere else, or using an existing remote object). However, it is a convenient short cut to creating objects. Lazy creation will not work once you assigned something else (like a null reference). </para +> <para +> The equivalent C++ terms would be <programlisting> + QWidget* w; + w->show(); +</programlisting +> which obviously in C++ just plain segfaults. So this is different here. This lazy creation is tricky especially as not necessarily an implementation exists for your interface. </para +> <para +> For instance, consider an abstract thing like a Arts::PlayObject. There are certainly concrete PlayObjects like those for playing mp3s or wavs, but <programlisting> + Arts::PlayObject po; + po.play(); +</programlisting +> will certainly fail. The problem is that although lazy creation kicks in, and tries to create a PlayObject, it fails, because there are only things like Arts::WavPlayObject and similar. Thus, use lazy creation only when you are sure that an implementation exists. </para +> </listitem +> <listitem +> <para +> References may point to the same object </para +> <programlisting> + Arts::SimpleSoundServer s = Arts::Reference("global:Arts_SimpleSoundServer"); + Arts::SimpleSoundServer s2 = s; +</programlisting +> <para +> creates two references referring to the same object. It doesn't copy any value, and doesn't create two objects. </para +> </listitem +> <listitem +> <para +> All objects are reference counted So once an object isn't referred any longer by any references, it gets deleted. There is no way to explicitely delete an object, however, you can use something like this <programlisting> + Arts::Synth_PLAY p; + p.start(); + [...] + p = Arts::Synth_PLAY::null(); +</programlisting +> to make the Synth_PLAY object go away in the end. Especially, it should never be necessary to use new and delete in conjunction with references. </para +> </listitem +> </itemizedlist> + +</sect2> + +<sect2 id="references-failure"> +<title +>The case of failure</title> + +<para +> As references can point to remote objects, the servers containing these objects can crash. What happens then? </para> + +<itemizedlist +> <listitem +> <para +> A crash doesn't change whether a reference is a null reference. This means that if <function +>foo.isNull()</function +> was <returnvalue +>true</returnvalue +> before a server crash then it is also <returnvalue +>true</returnvalue +> after a server crash (which is clear). It also means that if <function +>foo.isNull()</function +> was <returnvalue +>false</returnvalue +> before a server crash (foo referred to an object) then it is also <returnvalue +>false</returnvalue +> after the server crash. </para +> </listitem +> <listitem +> <para +> Invoking methods on a valid reference stays safe Suppose the server containing the object calc crashed. Still calling things like <programlisting> + int k = calc.subtract(i,j) +</programlisting +> are safe. Obviously subtract has to return something here, which it can't because the remote object no longer exists. In this case (k == 0) would be true. Generally, operations try to return something <quote +>neutral</quote +> as result, such as 0.0, a null reference for objects or empty strings, when the object no longer exists. </para +> </listitem +> <listitem +> <para +> Checking <function +>error()</function +> reveals whether something worked. </para +> <para +> In the above case, <programlisting> + int k = calc.subtract(i,j) + if(k.error()) { + printf("k is not i-j!\n"); + } +</programlisting +> would print out <computeroutput +>k is not i-j</computeroutput +> whenever the remote invocation didn't work. Otherwise <varname +>k</varname +> is really the result of the subtract operation as performed by the remote object (no server crash). However, for methods doing things like deleting a file, you can't know for sure whether it really happened. Of course it happened if <function +>.error()</function +> is <returnvalue +>false</returnvalue +>. However, if <function +>.error()</function +> is <returnvalue +>true</returnvalue +>, there are two possibilities: </para +> <itemizedlist +> <listitem +> <para +> The file got deleted, and the server crashed just after deleting it, but before transferring the result. </para +> </listitem +> <listitem +> <para +> The server crashed before beeing able to delete the file. </para +> </listitem +> </itemizedlist +> </listitem +> <listitem +> <para +> Using nested invocations is dangerous in crash resistent programs </para +> <para +> Using something like <programlisting> + window.titlebar().setTitle("foo"); +</programlisting +> is not a good idea. Suppose you know that window contains a valid Window reference. Suppose you know that <function +>window.titlebar()</function +> will return a Titlebar reference because the Window object is implemented properly. However, still the above statement isn't safe. </para +> <para +> What could happen is that the server containing the Window object has crashed. Then, regardless of how good the Window implementation is, you will get a null reference as result of the window.titlebar() operation. And then of course invoking setTitle on that null reference will lead to a crash as well. </para +> <para +> So a safe variant of this would be <programlisting> + Titlebar titlebar = window.titlebar(); + if(!window.error()) + titlebar.setTitle("foo"); +</programlisting +> add the appropriate error handling if you like. If you don't trust the Window implementation, you might as well use <programlisting> + Titlebar titlebar = window.titlebar(); + if(!titlebar.isNull()) + titlebar.setTitle("foo"); +</programlisting +> which are both safe. </para +> </listitem +> </itemizedlist> + +<para +> There are other conditions of failure, such as network disconnection (suppose you remove the cable between your server and client while your application runs). However their effect is the same like a server crash. </para> + +<para +> Overall, it is of course a consideration of policy how strictly you try to trap communcation errors throughout your application. You might follow the <quote +>if the server crashes, we need to debug the server until it never crashes again</quote +> method, which would mean you need not bother about all these problems. </para> + +</sect2> + +<sect2 id="references-internals"> +<title +>Internals: Distributed Reference Counting</title> + +<para +> An object, to exist, must be owned by someone. If it isn't, it will cease to exist (more or less) immediately. Internally, ownership is indicated by calling <function +>_copy()</function +>, which increments an reference count, and given back by calling <function +>_release()</function +>. As soon as the reference count drops to zero, a delete will be done. </para> + +<para +> As a variation of the theme, remote usage is indicated by <function +>_useRemote()</function +>, and dissolved by <function +>_releaseRemote()</function +>. These functions lead a list which server has invoked them (and thus owns the object). This is used in case this server disconnects (&dh; crash, network failure), to remove the references that are still on the objects. This is done in <function +>_disconnectRemote()</function +>. </para> + +<para +> Now there is one problem. Consider a return value. Usually, the return value object will not be owned by the calling function any longer. It will however also not be owned by the caller, until the message holding the object is received. So there is a time of <quote +>ownershipless</quote +> objects. </para> + +<para +> Now, when sending an object, one can be reasonable sure that as soon as it is received, it will be owned by somebody again, unless, again, the receiver dies. However this means that special care needs to be taken about object at least while sending, probably also while receiving, so that it doesn't die at once. </para> + +<para +> The way &MCOP; does this is by <quote +>tagging</quote +> objects that are in process of being copied across the wire. Before such a copy is started, <function +>_copyRemote</function +> is called. This prevents the object from being freed for a while (5 seconds). Once the receiver calls <function +>_useRemote()</function +>, the tag is removed again. So all objects that are send over wire are tagged before transfer. </para> + +<para +> If the receiver receives an object which is on his server, of course he will not <function +>_useRemote()</function +> it. For this special case, <function +>_cancelCopyRemote()</function +> exists to remove the tag manually. Other than that, there is also timer based tag removal, if tagging was done, but the receiver didn't really get the object (due to crash, network failure). This is done by the <classname +>ReferenceClean</classname +> class. </para> + +</sect2> + +</sect1> + +<sect1 id="detail-gui-elements"> +<title +>&GUI;-Elemente</title> + +<para +> &GUI;-Elemente sind augenblicklich in einem experimentellen Stadium. Dieser Abschnitt beschreibt also, wie &arts; später einmal mit &GUI;-Elementen umgehen soll. Außerdem ist ein gewisser Teil an Programmzeilen bereits vorhanden. </para> + +<para +> &GUI;-Elemente dienen der Interaktion eines Benutzers mit synthetisierten Strukturen. Im einfachsten Fall soll der Benutzer in der Lage sein, einige Parameter der Struktur direkt zu verändern (z.B. einen Verstärkungsfaktor, der vor dem Abspielmodul verwendet wird). </para> + +<para +> In einem komplexeren Fall wäre vorstellbar, das ein Benutzer Parameter einer ganzen Gruppe von Strukturen oder noch nicht ausgeführten Strukturen ändert, wie z.B. die <acronym +>ADSR</acronym +>-Hüllkurve (envelope) des aktiven &MIDI;-Instrumentes. Eine andere denkbare Einstellung wäre der Dateiname eines Instrumentes, das auf einem Sample basiert. </para +> + +<para +> Auf der anderen Seite könnte der Benutzer überwachen wollen, was innerhalb des Synthesizers passiert. Dazu könnte es Oszilloskope, Spektrumanalysatoren, Lautstärkeanzeigen und <quote +>Experimente</quote +> geben, um z.B. in der Lage zu sein, den Frequenzgang eines bestimmten Filtermodules zu analysieren. </para> + +<para +> Schließlich sollte es möglich sein, mit &GUI;-Elementen die gesamte Struktur zu kontrollieren, die in &arts; ausgeführt wird. Der Benutzer sollte in der Lage sein, Instrumente &MIDI;-Kanälen zuzuordnen, neue Effekte zu starten und zu seinem Hauptmischpult (das ebenfalls aus &arts;-Strukturen besteht) einen weiteren Kanal hinzuzufügen und eine neue Strategie für seine Equalizer einzustellen. </para> + +<para +> Die &GUI;-Elemente bieten dem Benutzer damit Zugriff auf alle Möglichkeiten, die das virtuelle Studio &arts; bietet. Natürlich sollen die &GUI;-Elemente auch mit &MIDI;-Eingaben interagieren können (ein Schieberegler soll sich selbstständig in eine neue Position bewegen, wenn ein Midi-Ereignis gerade diesen Parameter geändert hat), weiterhin sollen die Elemente selbst Ereignisse generieren können, um die Aufnahme der Benutzereingaben zu ermöglichen. </para> + +<para +> Technisch gesprochen benötigt man eine &IDL;-Basisklasse für alle Kontrollelemente (<classname +>Arts::Widget</classname +>) und kann von dieser eine Anzahl häufig verwendeter Kontrollelemente (wie <classname +>Arts::Poti</classname +>, <classname +>Arts::Panel</classname +>, <classname +>Arts::Window</classname +>, ...) ableiten. </para> + +<para +> Diese Kontrollelemente sollten mit einer Bibliothek wie &Qt; oder Gtk implementiert werden. Schließlich sollten die &GUI;s der Effekte aus diesen Elementen gebildet werden. Ein Freeverb-Effekt könnte z.B. aus fünf <classname +>Arts::Poti</classname +>- und einem <classname +>Arts::Window</classname +>-Element gebildet werden. Wenn es also eine &Qt;-Implementation dieser grundlegenden Elemente gibt, kann der Effekt sich mit Hilfe von &Qt; darstellen. Wenn es eine Gtk-Implementation gibt, funktioniert das für Gtk ebenfalls (die Funktionsweise sollte mehr oder weniger gleichwertig sein). </para> + +<para +> Da wir &IDL; benutzen, sollte &arts-builder; (oder andere Programme) in der Lage sein, &GUI;s optisch zusammenzuführen oder mit einigen Parametern basierend auf den Schnittstellen selbst zusammenzustellen. Es sollte relativ einfach sein, eine <quote +>GUI nach Beschreibung erstellen</quote +>-Klasse zu programmieren, die eine &GUI;-Beschreibung (in der Form Parameter und Kontrollelement) in ein &GUI;-Objekt umsetzt. </para> + +<para +> Basierend auf &IDL; und dem &arts;/&MCOP;-Komponentenmodell sollte es genau so leicht sein, ein neues &GUI;-Objekt zu erstellen, wie es ist, ein neues Plugin für &arts; zu schreiben, das einen weiteren Filter bereitstellt. </para> + +</sect1> + +</chapter> + + + diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/digitalaudio.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/digitalaudio.docbook new file mode 100644 index 00000000000..46b868f0821 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/digitalaudio.docbook @@ -0,0 +1,16 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE appendix PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<appendix id="intro-digital-audio"> +<title +>Einführung in digitale Audiobearbeitung</title> + +<para +>digitales Sampling, Filter, Effekte, &etc;</para> + +</appendix> + + + diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/faq.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/faq.docbook new file mode 100644 index 00000000000..ff9e1d5df97 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/faq.docbook @@ -0,0 +1,1312 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> +<chapter id="faq"> +<title +>Fragen und Antworten</title> + +<para +>In diesem Abschnitt finden Sie die Antworten auf einige häufig gestellte Fragen zu &arts;. </para> + +<qandaset id="faq-general"> +<title +>Allgemeine Fragen</title> + +<qandaentry> +<question> +<para +>Unterstützt &kde; die Ausgabe von Audio über meine Soundkarte? </para> +</question> + +<answer> +<para +>&kde; verwendet &arts; für das Abspielen von Klängen und &arts; verwendet die Kernel-Treiber von &Linux;, entweder <acronym +>OSS</acronym +> oder die <acronym +>OSS</acronym +>-Emulation von <acronym +>ALSA</acronym +>. Wenn Ihre Soundkarte entweder von <acronym +>ALSA</acronym +> oder <acronym +>OSS</acronym +> unterstützt und richtig eingerichtet wurde (&dh; irgendeine andere &Linux;-Anwendung kann Klänge ausgeben), funktionieren auch Klänge unter KDE. In speziellen Fällen können allerdings Probleme auftreten. Bei Problemen mit artsd kann man den <link linkend="faq-hardware-specific" +>Abschnitt über Hardware-Probleme</link +> lesen. </para> +<para +>Inzwischen werden verschiedene andere Computersysteme unterstützt. Es folgt eine komplette Liste der Soundausgabe mit der aktuellen Version von &arts;. Falls das eigene Computersystem nicht aufgeführt ist, sollte man in Erwägung ziehen, &arts; selbst zu portieren. </para> + +<informaltable> +<tgroup cols="2"> +<thead> +<row> +<entry +>&arts; Audio Ein-/Ausgabe-Methode</entry> +<entry +>Kommentar</entry> +</row> +</thead> + +<tbody> +<row> +<entry +>paud</entry> +<entry +>Unterstützung des "Personal Audio Device" unter AIX</entry> +</row> + +<row> +<entry +>alsa</entry> +<entry +>Linux ALSA-0.5- und ALSA-0.9-Treiber</entry> +</row> + +<row> +<entry +>libaudioio</entry> +<entry +>Unterstützung der unter Solaris funktionierenden generischen Bibliothek "LibAudioIO"</entry> +</row> + +<row> +<entry +>nas</entry> +<entry +>NAS-Soundserver, nützlich für X-Terminals mit NAS-Unterstützung</entry> +</row> + +<row> +<entry +>null</entry> +<entry +>Null-Audiogerät, verwirft Soundausgaben</entry> +</row> + +<row> +<entry +>oss</entry> +<entry +>OSS-Unterstützung (Open Sound System) (funktioniert unter Linux, verschiedenen BSD-Varianten und anderen Plattformen mit installierten OSS-Treibern)</entry> +</row> + +<row> +<entry +>toss</entry> +<entry +>OSS-Unterstützung mit Threads, funktioniert manchmal in Installaionen besser, unter denen die Standardunterstützung für OSS versagt</entry> +</row> + +<row> +<entry +>sgi</entry> +<entry +>SGI "Direct Media"-Unterstützung unter IRIX</entry> +</row> + +<row> +<entry +>sun</entry> +<entry +>Solaris-Unterstützung</entry> +</row> + +</tbody> +</tgroup> +</informaltable> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Ich kann keine <literal role="extension" +>wav</literal +>-Dateien mit &artsd; abspielen! </para> +</question> + +<answer> +<para +>Überprüfen Sie, das &artsd; mit<filename +>libaudiofile</filename +> gelinkt ist (<userinput +><command +>ldd</command +> <parameter +>artsd</parameter +></userinput +>). Falls das nicht der Fall ist, laden Sie das Paket tdesupport herunter und übersetzen Sie alles neu. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Ich kann Klänge hören, wenn ich mich als <systemitem class="username" +>root</systemitem +> anmelde, aber kein anderer Benutzer kann Klänge hören! </para> +</question> + +<answer> +<para +>Die Berechtigungen für die Datei <filename class="devicefile" +>/dev/dsp</filename +> entscheiden, welche Benutzer Klänge erhalten. Um jedem die erforderlichen Berechtigungen zu geben, müssen Sie Folgendes machen: </para> + +<procedure> +<step> +<para +>Melden Sie sich als <systemitem class="username" +>root</systemitem +> an. </para> +</step> + +<step> +<para +>Öffnen Sie ein &konqueror;-Fenster. </para> +</step> + +<step> +<para +>Gehen Sie in den Ordner <filename class="directory" +>/dev</filename +>. </para> +</step> + +<step> +<para +>Klicken Sie mit der <mousebutton +>rechten</mousebutton +> Maustaste auf <filename +>dsp</filename +> und wählen Sie Eigenschaften. </para> +</step> + +<step> +<para +>Klicken Sie auf die Karteikarte <guilabel +>Berechtigungen</guilabel +>. </para> +</step> + +<step> +<para +>Markieren Sie <guilabel +>Lesen</guilabel +> und <guilabel +>Schreiben</guilabel +> in allen Bereichen. </para> +</step> + +<step> +<para +>Klicken Sie auf <guibutton +>OK</guibutton +>. </para> +</step> +</procedure> + +<para +>Sie können das gleiche erreichen, indem Sie in einem Terminal-Fenster <userinput +><command +>chmod</command +> <option +>666</option +> <parameter +>/dev/dsp</parameter +></userinput +> eingeben. </para> + +<para +>Um den Zugriff auf Klänge auf bestimmte Benutzer einzuschränken, können Sie Gruppenrechte verwenden. Bei einige &Linux;-Distributionen, z.B. Debian/Potato, gehört <filename class="devicefile" +>/dev/dsp</filename +> bereits zur Gruppe <systemitem class="groupname" +>audio</systemitem +>. Sie müssen die gewünschten Benutzer lediglich zu dieser Gruppe hinzufügen. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Das hilft für &artsd;, aber wie sieht es mit &kmix;, &kmid;, &kscd;,&etc; aus? </para> +</question> +<answer> + +<para +>Es gibt verschiedene andere Geräte, auf die Multimedia-Anwendungen zugreifen. Sie können sie alle genau so behanden; Sie können sie entweder für alle Benutzer freigeben oder Gruppenrechte zur Zugriffskontrolle verwenden. Hier ist eine Liste der beteiligten Geräte, die aber unvollständig sein kann (falls es mehrere Geräte einer Art gibt, sind sie in der Form <filename class="devicefile" +>midi0</filename +>, <filename class="devicefile" +>midi1</filename +>, ... benannt, nur das erste dieser Geräte ist in der folgenden Liste aufgeführt): </para> + +<itemizedlist> +<listitem> +<para> +<filename class="devicefile" +>/dev/admmidi0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/adsp0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/amidi0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/amixer0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/audio</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/audio0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/cdrom</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/dmfm0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/dmmidi0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/dsp</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/dsp0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/midi0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/midi0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/midi00</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/midi00</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/mixer</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/mixer0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/mpu401data</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/mpu401stat</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/music</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/rmidi0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/rtc</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/sequencer</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/smpte0</filename> +</para> +</listitem> +<listitem> +<para> +<filename class="devicefile" +>/dev/sndstat</filename> +</para> +</listitem> +</itemizedlist> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Was kann ich tun, wenn artsd nicht startet oder während der Ausführung abstürzt?</para> +</question> + +<answer> +<para +>Versuchen Sie zuerst die Standardeinstellungen in &kcontrol; (oder wenn Sie manuell gestartet haben, geben Sie keine zusätzlichen Optionen an, außer vielleicht <userinput +><option +>-F</option +><parameter +>10</parameter +> <option +>-S</option +><parameter +>4096</parameter +></userinput +>). Besonders die Einstellung <emphasis +>Volle Duplexfähigkeit aktivieren</emphasis +> funktioniert bei einigen Treibern <emphasis +>nicht</emphasis +>. </para> + +<para +>Eine gute Methode, Problemen mit artsd auf den Grund zu gehen, ist, &artsd; manuell zu starten. Öffnen Sie dazu ein &konsole;-Fenster und geben Sie folgenden Befehl: </para> + +<screen width="40" +><prompt +>%</prompt +> <userinput +><command +>artsd</command +> <option +>-F</option +><parameter +>10</parameter +> <option +>-S</option +><parameter +>4096</parameter +></userinput +></screen> + +<para +>Sie können außerdem die Option <option +>-l0</option +> hinzufügen. Sie sorgt für umfangreichere Statusmeldungen: </para> +<screen width="40" +><prompt +>%</prompt +> <userinput +><command +>artsd</command +> <option +>-l0</option +> <option +>-F</option +><parameter +>10</parameter +> <option +>-S</option +><parameter +>4096</parameter +></userinput +></screen> + +<para +>Sie erhalten bestimmt einige nützliche Informationen über die Startprobleme. Oder, wenn artsd abstürzt, während etwas Bestimmtes passiert, können Sie auch dieses ausprobieren und Informationen erhalten <quote +>wie</quote +> &artsd; abstürzt. Wenn Sie einen Fehlerbericht einsenden wollen, kann ein Backtrace mit <command +>gdb</command +> und/oder ein <command +>strace</command +> hilfreich sein. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Kann ich &artsd; verschieben (die übersetzten Dateien in einen anderen Ordner verschieben)?</para> +</question> + +<answer> +<para +>Das funktioniert nicht perfekt. Das Problem ist, das &artswrapper; die Position von &artsd; aus Sicherheitsgründen fest einkompiliert hat. Sie können allerdings die <filename +>.mcoprc</filename +>-Datei (Einträge für Trader-Pfad/Erweiterungspfad) verwenden, damit ein verschobener &artsd; wenigstens seine Komponenten findet. Sehen Sie im <link linkend="the-mcoprc-file" +>Kapitel über die <filename +>.mcoprc</filename +>-Datei</link +> für genauere Vorgehenshinweise nach. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Kann man &arts; mit gcc-3.0 kompilieren?</para> +</question> + +<answer> +<para +>Kurze Antwort: Nein, &arts; funktioniert nicht, wenn er mit GCC 3.0 kompiliert wird. </para> + +<para +>Lange Antwort: In der offiziellen Version von GCC 3.0 gibt es zwei Fehler, die &arts; betreffen. Der Erste, GCC-Fehler c++/2733 ist relativ harmlos (und betrifft Probleme mit Assembleranweisungen). Die Kompilation von convert.cc wird dadurch verhindert. Dieser Fehler ist im GCC-3.0-CVS bereits beseitigt und wird in einer Version GCC-3.0.1 oder höher beseitigt sein. Ein Notbehelf wurde zur CVS-Version von KDE/arts hinzugefügt. </para> +<para +>Der zweite GCC-3.0-Fehler, c++/3145 (Erzeugung falscher Anweisungen in einigen Fällen von mehrfacher virtueller Vererbung) ist kritisch. Anwendng wie &artsd; stürzen ab beim Start ab, wenn sie mit GCC-3.0 kompiliert werden. Auch wenn bereits kleine Fortschritte zur Beseitigung dieses Problems erzielt wurden, stürzt &artsd; immer noch oft und unerwartet ab. </para> +</answer> +</qandaentry> +<qandaentry> +<question> +<para +>Welche Anwendungen funktionieren unter &arts;?</para> +</question> +<answer> + +<para +>Offensichtlich sind alle &kde;-Anwendungen für &arts; vorbereitet. Das schließt Folgende ein: </para> + +<itemizedlist> +<listitem +><para +>&noatun;</para +></listitem> +<listitem +><para +>&arts-builder;</para +></listitem> +<listitem +><para +>&aktion;</para +></listitem> +<listitem +><para +>&kmid;</para +></listitem> +<listitem +><para +>&kmidi;</para +></listitem> +<listitem +><para +>&kmix;</para +></listitem> +<listitem +><para +>&kscd;</para +></listitem> +<listitem +><para +>&kde;-Spiele wie &kpoker; und &ktuberling;</para +></listitem> +</itemizedlist> + +<para +>Einige &kde;-Anwendungen, die bisher nicht Teil von &kde;-Veröffentlichungen sind (z.B. aus kdenonbeta) unterstützen &arts; auch. Das sind unter anderen: </para> + +<itemizedlist> +<listitem +><para +>&brahms;</para +></listitem> +<listitem +><para +><application +>Kaboodle</application +></para +></listitem> +<listitem +><para +><application +>Kdao</application +></para +></listitem> +</itemizedlist> + +<para +>Die folgenden Nicht-&kde;-Anwendungen funktionieren ebenfalls mit &arts;: </para> + +<itemizedlist> +<listitem +><para +><application +>xmms</application +> (mit &arts;-Plugin)</para +></listitem> +<listitem +><para +>Real Networks <application +>RealPlayer</application +> 8.0 (funktioniert mit &artsdsp;; vollständige &arts;-Unterstützung wird überlegt)</para +></listitem> +</itemizedlist> + +<para +>Die folgenden Anwendungen funktionieren <emphasis +>nicht</emphasis +> mit &arts;: </para> + +<itemizedlist> +<listitem +><para +>keine</para +></listitem> +</itemizedlist> + +<para +>Weitere Informationen finden Sie in den Antworten zu den Fragen im Abschnitt <link linkend="faq-non-arts" +>Nicht-&arts;-Anwendungen</link +>. </para> + +<para +>Dieser Abschnitt ist unvollständig -- wenn Sie Informationen zu weiteren unterstützten und nicht unterstützten Anwendungen haben, senden Sie sie an den Autor, damit sie eingefügt werden können. </para> +</answer> +</qandaentry> + +</qandaset> + +<qandaset id="faq-non-arts"> +<title +>Nicht-&arts;-Anwendungen</title> + +<qandaentry> +<question> +<para +>Sobald &kde; läuft, kann keine andere Anwendung auf die Klanggeräte zugreifen! </para> +</question> +<answer> +<para +>Während der &arts;-Soundserver von &kde; läuft, verwendet er die Klanggeräte. Wenn der Server für 60 Sekunden unbeschäftigt ist, setzt er aus und gibt die Geräte automatisch frei. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Angeblich soll er nach 60 Sekunden aussetzen, er tut es aber nicht! </para> +</question> +<answer> +<para +>Wenn man artsd vom KDE Kontrollzentrum aus startet, beträgt die Standardeinstellung für das Aussetzen 60 Sekunden. Wenn man artsd dagegen von der Befehlszeile aus startet, muss man die Option -s verwenden, um die Zeit bis zum Aussetzen festzulegen, ansonsten wird das Aussetzen deaktiviert. </para> +<para +>Augenblicklich funktioniert das Aussetzen nicht im Zusammenhang mit Full-Duplex. Schalten Sie in &kcontrol; Full-Duplex-Fähigkeit aus und das Aussetzen wird funktionieren. Full-Duplex deaktivieren, ist immer einer gute Idee, wenn Sie &arts; nur zum Abspielen und nicht zum Aufnehmen verwenden. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Wie kann ich alte Nicht-&arts;-Anwendungen ausführen? </para> +</question> + +<answer> +<para +>Starten Sie sie mit Hilfe von &artsdsp;. Wenn Sie z.B. normalerweise eingeben würden: </para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>mpg123</command +> <option +>foo.mp3</option +></userinput +></screen> + +<para +>verwenden Sie stattdessen:</para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>artsdsp</command +> <option +>mpg123 foo.mp3</option +></userinput +></screen> + +<para +>Dadurch wird die Klangausgabe an &arts; umgeleitet. Diese Methode erfordert keine Veränderung der Anwendungen. Diese Übergangslösung unterstützt allerdings bisher nicht alle Fähigkeiten der Klanggeräte, daher werden einige Anwendungen dennoch nicht funktionieren. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Ich kann &artsdsp; mit keiner Anwendung ausführen, es stürzt immer ab! </para> +</question> +<answer> +<para +>Sie benötigen eine aktuelle Version der glibc-Bibliothek; &artsdsp; funktioniert auf einigen älteren &Linux;-Distributionen nicht zuverlässig. Z.B. funktioniert das Programm unter Debian 2.1 (mit glibc 2.0) nicht, während es unter Debian 2.2 (mit glibc 2.1.3) funktioniert. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Gibt es prinzipielle Hindernisse, sodass einige Anwendungen grundsätzlich nicht mit &artsdsp; funktionieren können? </para> +</question> +<answer> +<para +>Nein. Das Programm &artsdsp; führt zu einer etwas höheren <acronym +>CPU</acronym +>-Belastung als die direkte Verwendung des &arts;-<acronym +>API</acronym +>s. Darüber hinaus kann jede nicht funktionierende Anwendung als Fehler in &artsdsp; betrachtet werden. Die Technik von &artsdsp; sollte bei richtiger Implementation<emphasis +>jeder</emphasis +> Anwendung eine Zusammenarbeit mit arts ermöglichen (einschließlich großer Anwendungen wie <application +>Quake</application +> 3). </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Was kann ich tun, wenn eine Anwendung nicht mit &artsdsp; funktioniert? </para> +</question> +<answer> +<para +>Sie können entweder warte, bis &artsd; automatisch aussetzt oder das Kommand <userinput +><command +>artsshell</command +> <option +>suspend</option +></userinput +> verwenden, um den Server manuelle abzuschalten. Sie können den Server nur dann abschalten, wenn keine Anwendung &arts; verwendet und während &arts; abgeschaltet ist, können Sie keine Anwendungen starten, die den Server verwenden. </para> + +<para +>Wenn der Server beschäftigt ist, gibt es einen brutalen Weg, ihn abzuschalten: </para> + + +<screen +><prompt +>%</prompt +> <userinput +><command +>killall</command +> <option +>artsd</option +> ; <command +>killall</command +> <option +>artswrapper</option +></userinput> +<lineannotation +>Now start your own application.</lineannotation> +<prompt +>%</prompt +> <userinput +><command +>kcminit</command +> <option +>arts</option +></userinput +> +</screen> + +<para +>Damit stürtzt allerdings jede &arts;-Anwendung ab, sobald Sie den Server so abschalten. </para> +</answer> +</qandaentry> +<qandaentry> +<question> +<para +>Wie sieht es mit &kde;-1.x-Anwendungen aus? </para> +</question> +<answer> +<para +>Wenn Sie &kde;-1.x-Anwendungen benutzen, die den &kde;-1-Audioserver zur Ausgabe verwenden, müssen Sie das Programm <application +>kaudioserver</application +> starten. Sie können <application +>kaudioserver</application +> wie jede andere Nicht-&arts;-Anwendung behandeln: </para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>artsdsp</command +> <option +>kaudioserver</option +></userinput +> +</screen> + +<para +>Sie müssen kaudioserver installiert haben (aus der gleichen Quelle, von der Sie Ihre &kde;-1.x-Anwendungen bekommen haben) - er gehört zu &kde; 1.x, nicht &kde; 2. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Wie sieht es mit Anwendungen aus, die den Enlightened Sound Daemon, <acronym +>ESD</acronym +>, verwenden? </para> +</question> +<answer> +<para +>Der Fall ist ähnlich zu <application +>kaudioserver</application +>. Solche Anwendungen benötigen den Server esd. Sie können <command +>esd</command +> mit Hilfe von &artsdsp; starten und jede <acronym +>ESD</acronym +>-Anwendung sollte so funktionieren: </para> +<screen +><prompt +>%</prompt +> <userinput +><command +>artsdsp</command +> <option +>esd</option +></userinput +> +</screen> +<para +>Neuere Versionen von &arts; ( +>= 1.2.0) können auch auf den "enlightened sound daemon" anstelle der Soundkarte direkt ausgeben. In der Kommandozeile muss dann die -a Option verwendet werden. Zum Beispiel: </para> +<screen +><prompt +>%</prompt +> <userinput +><command +>artsd</command +> <option +>-a esd</option +></userinput +> +</screen> +<para +>um die EsounD-Unterstützung zu aktivieren. Im &kde; reicht es, in &kcontrol; "Sound & Multimedia" / "Sound-System" die Audio-Hardware auf "Enlightened Sound Dämon" zu stellen. </para> +</answer> +</qandaentry> + +</qandaset> + +<qandaset id="faq-latency"> +<title +>Aussetzer</title> + +<qandaentry> +<question> +<para +>Manchmal höre ich kurze Aussetzer in der Musik, ist das ein Fehler? </para> +</question> +<answer> +<para +>Das ist höchstwahrscheinlich kein Fehler sondern durch die Tatsache verursacht, das der &Linux;-Kernel keine guten Echtzeit-Fähigkeiten besitzt. Es gibt Situationen, in denen &arts; nicht mit der Wiedergabe mithalten kann.Sie können allerdings Echtzeit-Priorität aktivieren (in &kcontrol;) und eine große Antwortzeit verwenden (wie <guilabel +>250ms</guilabel +> oder <guilabel +>so groß wie möglich</guilabel +>). Das sollte die Situation verbessern. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Wie wirkt sich der Antwortzeitwert aus? </para> +</question> +<answer> +<para +>Der Hilfetext für diese Einstellung in &kcontrol; kann verwirren. Ein kleinerer Wert bedeutet, das &arts; eine kürzere Antwortzeit auf externe Ereignisse (&dh; die Zeit, die benötigt wird zwischen dem Schließen eines Fensters und dem von &artsd; abgespielten zugehörigen Klang) verwendet. Das bedeutet, das mehr <acronym +>CPU</acronym +>-Zeit benötigt wird und die Wahrscheinlichkeit von Aussetzern größer wird.</para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Gibt es andere Einstellungen, die Aussetzer verhindern können? </para> +</question> +<answer> +<para +>Benutzer von <acronym +>IDE</acronym +>-Laufwerken, können das Programm <command +>hdparm</command +> verwenden, um ihr <acronym +>IDE</acronym +>-Laufwerk in den <acronym +>DMA</acronym +>-Modus umzuschalten. Eine Warnung: Dieser Modus funktioniert nicht auf jedem Computer und kann zu einem Systemgesamtabsturz und in seltenen Fällen zu Datenverlust führen. Lesen Sie die Dokumentation zu <command +>hdparm</command +> für genauere Informationen. Ich habe das folgende Kommando erfolgreich verwendet: </para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>hdparm</command +> <option +>-c1</option +> <option +>-d1</option +> <option +>-k1</option +> <option +>-K1</option +> <parameter +>/dev/hda</parameter +></userinput +> +</screen> + +<para +>Sie müssen dieses Kommando nach jedem Neustart ausführen, es ist also in einem Start-Skript am besten aufgehoben (wo genau ist unterschiedlich, auf Debian &Linux; üblicherweise in <filename +>/etc/rc.boot</filename +>). </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Die Verwendungvon Echtzeit-Priorität scheint keinen Einfluss zu haben? </para> +</question> +<answer> +<para +>Überprüfen Sie, ob artswrapper als suid <systemitem class="username" +>root</systemitem +> installiert ist. Viele Distributionen (wie z.B. SuSE7.x) installieren artswrapper nicht mit den richtigen Berechtigungen. Zur Überprüfung tippen Sie: ls -l $(which artswrapper). So sollte die Ausgabe aussehen: <screen> +<prompt +>%</prompt +> <userinput +><command +>ls</command +> <option +>-l</option +> <parameter +>$(which artswrapper)</parameter +></userinput> +-rwsr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde2/bin/artswrapper +</screen +> So sollte es nicht aussehen: <screen> +<prompt +>%</prompt +> <userinput +><command +>ls</command +> <option +>-l</option +> <parameter +>$(which artswrapper)</parameter +></userinput> +-rwxr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde2/bin/artswrapper +</screen +> Wenn das s fehlt, kann man es durch folgenden Befehl hinzufügen: <screen +><prompt +>%</prompt +> <userinput +><command +>chown</command +> <option +>root</option +> <parameter +>$(which artswrapper)</parameter +></userinput> +<prompt +>%</prompt +> <userinput +><command +>chmod</command +> <option +>4755</option +> <parameter +>$(which artswrapper)</parameter +></userinput +> +</screen> +</para> + +<para +>Falls man &artswrapper; als SUID <systemitem class="username" +>root</systemitem +> ausführen lässt, wird sich durch Verringerung der Unterbrechungen die Qualität der Musikwiedergabe vermutlich erhöhen. Das erhöht allerdings auch die Wahrscheinlichkeit, dass ein Fehler im Programm oder ein böswilliger Benutzer den Rechner beschädigt. Im Mehr-Benutzerbetrieb kann die Ausgabe von hochwertigen Musikaufnahmen die Geschwindigkeit anderer Programme und Benutzer, die <quote +>produktiv</quote +> arbeiten, ernsthaft in Mitleidenschaft ziehen.</para> + +</answer> +</qandaentry> + + +<qandaentry> +<question> +<para +>Warum benötigt &artsd; so viel <acronym +>CPU</acronym +>-Zeit? </para> +</question> +<answer> +<para +>Überprüfen Sie Ihre Antwortzeit-Einstellung. Die aktuelle Version ist außerdem noch nicht optimiert. Das wird sich in Zukunft verbessern. Bis dahin ist keine richtige Vorhersage möglich, wie schnell &artsd; sein kann oder nicht sein kann. </para> +</answer> +</qandaentry> +</qandaset> + +<qandaset id="faq-network"> +<title +>Netzwerk-Transparenz</title> + +<qandaentry> +<question> +<para +>Was benötige ich für Netzwerk-Transparenz? </para> +</question> +<answer> +<para +>Sie müssen Netzwerk-Transparenz in den <guilabel +>Soundserver</guilabel +>-Einstellungen von &kcontrol; aktivieren (<guilabel +>Sicherheits- und Transparenzinfo mittels X11-Server austauschen</guilabel +> und <guilabel +>Netzwerk-Transparenz aktivieren</guilabel +>). Kopieren Sie Ihre <filename +>.mcoprc</filename +>-Datei auf alle Computer, von denen Sie diese Fähigkeit verwenden wollen. Melden Sie sich neu an. Stellen Sie sicher, das die Namensauflösung zwischen den interagierenden Computern funktioniert (&dh; sie müssen auflösbare Namen haben oder in der Datei <filename +>/etc/hosts</filename +> eingetragen sein). </para> + +<para +>Das sollte alles sein. Falls immer noch Probleme bestehen, sind hier noch weitere Informationen. Der &arts; Soundserver-Prozess, &artsd;, sollte nur auf einem Computer laufen, demjenigen mit der Soundkarte, auf dem die Ausgabe erfolgen soll. Der Prozess kann automatisch beim Anmelden von &kde; gestartet werden (wenn Sie das in &kcontrol; einstellen), oder manuell durch Eingabe von: </para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>artsd</command +> <option +>-n</option +> <option +>-F</option +> <parameter +>5</parameter +> <option +>-S</option +> <parameter +>8192</parameter +></userinput +> +</screen> + +<para +>Die Option <option +>-n</option +> ist für Netzwerk-Transparenz, die anderen steuern die Antwortzeit. </para> + +<para +>Ihre <filename +>.mcoprc</filename +>-Datei sollte folgenden Eintrag haben: </para> + +<screen +><userinput +>GlobalComm=Arts::X11GlobalComm</userinput +> +</screen> + +<para +>auf allen beteiligten Computern, damit die Netzwerk-Transparenz funktioniert. Das wird aktiviert durch die Kontrollzentrumseinstellung <guilabel +>Sicherheits- und Transparenzinfo mittels X11-Server austauschen</guilabel +>. </para> + +<para +>Schließlich gibt es in jeder &kde;-Version aus der 2.0.x-Serie einen Fehler, der sich auswirkt, wenn kein Domain-Name eingetragen ist. Klienten von &artsd; suchen den Computer mit dem Soundserver durch die <systemitem class="systemname" +><replaceable +>hostname</replaceable +>. <replaceable +>domainname</replaceable +></systemitem +>-Kombination. Wenn Ihr Domain-Name leer ist, wird <systemitem class="systemname" +><replaceable +>hostname</replaceable +></systemitem +>. (beachten Sie den zusätzlichen Punkt). Fügen Sie einen solchen Eintrag in die Datei <filename +>/etc/hosts</filename +> (&dh; <userinput +>orion.</userinput +> wenn Ihr Host-Name <systemitem class="systemname" +>orion</systemitem +> lautet) ein, um das Problem zu umgehen. </para> +</answer> +</qandaentry> + + +<qandaentry> +<question> +<para +>Wie kann ich Fehler suchen, falls die Netzwerk-Transparenz nicht funktioniert? </para> +</question> +<answer> +<para +>Wenn Sie den &kde;-Quelltext haben, gehen Sie in <filename class="directory" +>tdelibs/arts/examples</filename +> und führen Sie <userinput +><command +>make</command +> <option +>check</option +></userinput +> aus, um einige Programme einschließlich <application +>referenceinfo</application +> zu übersetzen. Führen Sie dann </para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>./referenceinfo</command +> <option +>global:Arts_SimpleSoundServer</option +></userinput +> +</screen> + +<para +> aus. Die Ausgabe zeigt den Hostnamen und die von &arts; verwendeten Kanäle (ports) an. Die Ausgabe <computeroutput +>tcp:orion:1698</computeroutput +> bedeutet, das jeder Klient, der Netzwerk-Transparenz verwenden will, sollte wissen, wie der Computer <systemitem class="systemname" +>orion</systemitem +> zu finden ist. </para> +</answer> +</qandaentry> + +</qandaset> + +<qandaset id="faq-hardware-specific"> +<title +>Hardware-spezifische Fragen</title> + +<qandaentry> +<question> +<para +>Welche Hardware funktioniert mit artsd nicht gut? </para> +</question> +<answer> +<para +>Es scheint, als würden einige wenige Linuxtreiber in manchen Kernelversionen nicht gut mit aRts zusammenarbeiten. Bitte lesen sie die folgende Liste, bevor Sie einen Fehler melden. Wenn Sie Unvollständigkeiten finden, zögern Sie bitte nicht, diese uns zu melden. <informaltable +> <tgroup cols="4"> +<thead> +<row> +<entry +>Linuxtreiber / Soundkarte</entry> +<entry +>Versagt unter</entry> +<entry +>Arbeitet unter</entry> +<entry +>Bemerkungen</entry> +</row> +</thead> + +<tbody> +<row> +<entry +>i810 driver (Intel 810 + AC97 Audio)</entry> +<entry +>2.4.9</entry> +<entry +>2.4.18, 2.2.20, kommerzieller OSS-Treiber, alsa-0.5.12a mit OSS-Emulation</entry> +<entry +>Der Treiber verursacht einen "cpu-overload".</entry> +</row> + +<row> +<entry +>maestro 3/4 chipset</entry> +<entry +>2.4.9</entry> +<entry +>?</entry> +<entry +>Der Treiber verursacht manchmal einen "cpu-overload".</entry> +</row> + +<row> +<entry +>aureal8820, aureal8830 Treiber von sourceforge</entry> +<entry +>2.4.17</entry> +<entry +>?</entry> +<entry +>Der Treiber verursacht eine "Assertion" / "cpu-overload".</entry> +</row> + +<row> +<entry +>OSS Commercial 3.9.4g mit Aureal Vortex</entry> +<entry +>?</entry> +<entry +>?</entry> +<entry +>Das System hängt sich auf.</entry> +</row> + +<row> +<entry +>ymfpci</entry> +<entry +>2.4.0, 2.4.12</entry> +<entry +>2.4.17</entry> +<entry +>Der Treiber verursacht eine "Assertion".</entry> +</row> + + + +</tbody> +</tgroup> +</informaltable> +</para> +</answer> +</qandaentry> + + + +<qandaentry> +<question> +<para +>Warum gibt es hardwarespezifische Probleme und wie sind diese zu lösen? </para> +</question> +<answer> +<para +>Das übliche Problem ist, dass manche Treiber aRts ungenügende oder unrichtige Informationen darüber geben, wann Sounddaten geschrieben werden sollen. Die meisten OSS-Treiber liefern korrekte Informationen, aber nicht alle. </para> +<para +>Es ist zu bemerken, dass einige andere Anwendungen (wie z.B. xmms) ohne diese Daten auskommen und daher auch auf solcher Hardware fehlerfrei arbeiten. &arts; benötigt diese Daten aber und daher könnte artsd abstürzen. Dennoch handelt es sich um einen Treiberfehler und nicht um einen &arts;-Fehler. </para> +<para +>Es gibt zwei Symptome, an denen man erkennt, dass artsd mit einem fehlerhaften Treiber arbeitet. Entweder versucht artsd ständig, neue Daten zu schreiben, was aber fehlschlägt und schließlich zu einer sehr hohen <emphasis +>CPU-Last</emphasis +> und schließlich zum Programmende führt. Beim zweiten Symptom wird artsd mit falschen Informationen darüber versorgt, wie viele Daten zu schreiben sind. In diesem Fall stoppt artsd <emphasis +>mit einer Assertion</emphasis +> wie: <screen +>artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int): +Assertion `len == can_write' failed. +Aborted +</screen> +</para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Wo liegt das Problem, wenn eine hohe CPU-Last auftritt? </para> +</question> +<answer> +<para +>Normalerweise verwendet artsd select(), um herauszufinden, wann Daten geschrieben werden können. Danach wird ein ioctl(...GETOSPACE...) verwendet, um die Menge der zu schreibenden Daten herauszufinden. Schließlich werden die Daten tatsächlich geschrieben. </para> +<para +>Ein Problem tritt auf, falls artsd ständig aktiviert wird oder falls nur minimale Datenmenge zu schreiben sind. Nach der OSS-Dokumentation aktiviert select() einen Prozess nur dann, wenn mindestens ein Fragment zu schreiben ist. Falls artsd allerdings aktiviert wird und es ist lediglich eine sehr geringe Datenmenge zu schreiben, fährt artsd fort, nur geringe Datenmenge zu schreiben. Das führt schließlich zu einer hohen CPU-Last. </para> +<para +>Um das zu verhindern, darf der Treiber artsd nur dann aktivieren, wenn mindestens ein volles Fragment zu schreiben ist. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Wo liegt der Fehler, wenn die Assertion auftritt? </para> +</question> +<answer> +<para +>Normalerweise verwendet artsd select(), um herauszufinden, wann Daten geschrieben werden können. Danach wird ein ioctl(...GETOSPACE...) verwendet, um die Menge der zu schreibenden Daten herauszufinden. Schließlich werden die Daten tatsächlich geschrieben. </para> +<para +>Falls artsd nicht so viele Daten schreiben kann, wie ioctl anzeigt, wird eine Assertion ausgelöst. Um das zu beheben, sollte der Treiber die korrekte Größe des freien Speichers mitteilen. </para> +</answer> +</qandaentry> +</qandaset> + +<qandaset id="faq-other"> +<title +>Andere Themen</title> + +<qandaentry> +<question> +<para +>Ich kann &arts-builder; nicht verwenden. Er stürzt ab, wenn ich eine Struktur ausführen lassen will! </para> +</question> +<answer> +<para +>Der wahrscheinlichste Grund für dieses Problem ist die Verwendung von alten Strukturen oder Modulen, die von &kde;2-Version nicht mehr unterstützt werden. Unglücklicherweise bezieht sich die im Internet verfügbare Version auf &arts;-0.3.4.1, die lange überholt ist. Der am häufigsten berichtete Fehler ist der folgende: Wenn Struktur ausführen in &arts-builder; gestartet wird, erscheint die Fehlermeldung <errorname +>[artsd] Synth_PLAY: Audio-Subsystem wird schon verwendet.</errorname +> </para> + +<para +>Sie sollten Synth_AMAN_PLAY an Stelle von Synth_PLAY verwenden und das Problem verschwindet. Weitere Informationen finden Sie in der Hilfedatei zu &arts-builder; (betätigen Sie <keycap +>F1</keycap +> in &arts-builder;). </para> + +<para +>Aktuelle Versionen von &arts-builder; (&kde; 2.1 Beta 1 und später) haben eine Menge von Beispielen, die Sie verwenden können. </para> +</answer> +</qandaentry> + +</qandaset> + +</chapter> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/future.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/future.docbook new file mode 100644 index 00000000000..50a2b7b9749 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/future.docbook @@ -0,0 +1,401 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.1.2-Based Variant +V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="future-work"> +<title +>Künftige Arbeiten</title> + +<para +>&arts; entwickelt sich zu schnell, als das an dieser Stelle eine aktuelle Liste möglich wäre. Informationen zu Plänen finden Sie in der Datei TODO und in den <link linkend="mailing-lists" +>Mailinglisten</link +>. Sie sind eingeladen, sich bei der weiteren Planung und Implementation zu beteiligen. </para> + +<para +>Dieses in der Entwicklung befindliche Dokument versucht einen Überblick darüber zu geben, wie neue Technologien in &arts; integriert werden. Es behandelt folgende Themen: </para> + +<itemizedlist> +<listitem +><para +>Wie Schnittstellen funktionieren.</para +></listitem> +<listitem +><para +>Codecs: Dekodierung von mp3-Strömen in eine Form, so dass sie als Daten verwendet werden können.</para +></listitem> +<listitem +><para +>Video.</para +></listitem> +<listitem +><para +>Threading.</para +></listitem> +<listitem +><para +>Synchronisation.</para +></listitem> +<listitem +><para +>Dynamische Erweiterung / Maskierung.</para +></listitem> +<listitem +><para +>Dynamische Komposition.</para +></listitem> +<listitem +><para +>&GUI;</para +></listitem> +<listitem +><para +>&MIDI;</para +></listitem> +</itemizedlist> + +<para +>Dieses befindet sich in Arbeit. Es ist die Grundlage dafür, wie neue Technologien in &arts; integriert werden können. Man kann einen ungefähren Eindruck davon bekommen, wie solche Probleme gelöst werden. Sie können alles, was Sie hier sehen, korrigieren. </para> + +<para +>Programme, die &arts;-Technologie verwenden (bitte: koordinieren Sie Ihre Anstrengungen): </para> + +<itemizedlist> +<listitem> +<para +><application +>KPhone</application +> (Voice over <acronym +>IP</acronym +>) </para> +</listitem> + +<listitem> +<para +>&noatun; (Video- / Audiospieler) </para> +</listitem> + +<listitem> +<para +>&artscontrol; (Kontrollprogramm des Soundservers) </para> +</listitem> + +<listitem> +<para +><application +>Brahms</application +> (Musiksequencer) </para> +</listitem> + +<listitem> +<para +><application +>Kaiman</application +> (&kde;2-Medienspieler - kmedia2-kompatibel) </para> +</listitem> + +<listitem> +<para +><application +>mpglib</application +>/<application +>kmpg</application +> (<acronym +>mpg</acronym +> Audio- und Videowiedergabetechnologie) </para> +</listitem> + +<listitem> +<para +><application +>SDL</application +> (direkte Medienschicht für Spiele, noch nicht begonnen, aber wohl sinnvoll) </para> +</listitem> + +<listitem> +<para +><application +>electric ears</application +> (Der Autor hat mich kontaktiert - Status unbekannt) </para> +</listitem> +</itemizedlist> + +<sect1 id="interfaces-how"> +<title +>Wie Schnittstellen (interfaces) funktionieren</title> + +<!-- I think this is now obsolete and documented elsewhere ? --> + +<para +>&MCOP;-Schnittstellen sind die Grundlage des Konzeptes von &arts;. Sie sind das netzwerktransparente Äquivalent zu C++-Klassen. Sie sollten Ihre Programmentwicklung mit Schnittstellen durchführen. Die Schnittstellen bestehen aus vier Teilen: </para> + +<itemizedlist> +<listitem +><para +>Synchrone Ströme</para +></listitem> +<listitem +><para +>Asynchrone Ströme</para +></listitem> +<listitem +><para +>Methods</para +></listitem> +<listitem +><para +>Attributes</para +></listitem> +</itemizedlist> + +<para +>Diese können beliebig kombiniert werden. Neue Technologien sollten als Schnittstellen definiert werden. Lesen Sie die Abschnitte über asynchrone Ströme und synchrone Ströme, sowie den über die KMedia2-Schnittstelle. Es sind gute Beispiele für ihre Funktionsweise </para> + +<para +>Schnittstellen werden als <literal role="extension" +>.idl</literal +>-Code spezifiziert und mit dem <command +>mcopidl</command +>-Compiler übersetzt. Sie leiten die <classname +><replaceable +>Interfacename</replaceable +>_impl</classname +>-Klasse ab, um es zu implementieren und verwenden <function +>REGISTER_IMPLEMENTATION(Interfacename_impl)</function +>, um Ihre Objekt-Implementation in das &MCOP;-Objektsystem einzufügen. </para> + +</sect1> + +<sect1 id="codecs"> +<title +>Codecs - Datendekodierung</title> + +<para +>Die kmedia2-Schnittstellen erlauben Ihnen zu ignorieren, dass wav-Dateien, mp3-Dateien und viele andere Formate aus Datenströmen bestehen. Stattdessen können Sie Methoden implementieren, um sie abzuspielen. </para> + +<para +>Sie können eine Routine zum Laden von wav-Dateien schreiben, um wav-Dateien abzuspielen ( als PlayObject), aber niemand sonst kann Ihren Code verwenden. </para> + +<para +>Asynchrone Ströme sind eine Alternative. Sie definieren eine Schnittstelle, die die Übergabe von Datenblöcken ermöglichen. So sieht das in &MCOP; aus: </para> + +<programlisting +>interface Codec { + in async byte stream indata; + out async byte stream outdata; +}; +</programlisting> + + +<para +>Natürlich können Codecs Attribute verwenden, um zusätzliche Daten, wie Formatinformationen bereitzustellen. </para> + +<programlisting +>interface ByteAudioCodec { + in async byte stream indata; + out async byte stream outdata; + readonly attribute samplingRate, bits, channels; +}; +</programlisting> + +<para +>Dieser <interfacename +>ByteAudioCodec</interfacename +> kann zum Beispiel mit einem <interfacename +>ByteStreamToAudio</interfacename +>-Objekt verbunden werden, um einen Audio-Strom zu formen. </para> + +<para +>Andere Codec-Typen können stattdessen Video-Daten direkt ausgeben, wie </para> + +<programlisting +>interface VideoCodec { + in async byte stream indata; + out video stream outdata; /* note: video streams do not exist yet */ +}; +</programlisting> + +<para +>Meistens sollte ein Codec-Konzept verwendet werden anstatt einem <quote +>Sie wissen, wie man es abspielt und ich nicht</quote +>-Konzept, wie zum Beispiel <interfacename +>WavPlayObject</interfacename +> es praktiziert. Natürlich muss sich jemand hinsetzen und einige Versuche durchführen, bevor ein <acronym +>API</acronym +> festgeschrieben werden kann. </para> + +</sect1> + +<sect1 id="video"> +<title +>Video</title> + +<para +>Mein Vorschlag ist, Video als asynchronen Strom eines &MCOP;-Datentypen, der Bilder enthält, zu implementieren. Dieser Datentyp muss noch kreiert werden. Auf diese Weise könnten Plugins, die Video-Bilder verarbeiten in der gleichen Art wie Audio-Plugins verbunden werden. </para> + +<para +>Auf einige Dinge muss dabei geachtet werden: </para> + +<itemizedlist> +<listitem> +<para +>Es gibt die Farbmodelle <acronym +>RGB</acronym +> und <acronym +>YUV</acronym +>. </para> +</listitem> +<listitem> +<para +>Das Format sollte dem Strom aufgeprägt werden. </para> +</listitem> +<listitem> +<para +>Synchronisation ist wichtig. </para> +</listitem> +</itemizedlist> + +<para +>Es sollte möglich sein, die <classname +>VideoFrame</classname +>-Klasse so zu reimplementieren, das Daten im gemeinsam genutzten Speicher gespeichert werden können. Damit würde auch Video-Streaming zwischen verschiedenen Prozessen ohne große Probleme möglich. </para> + +<para +>Bisher befindet sich für Videodaten von der Dekodierung bis zum Rendern alles im gleichen Prozess. </para> + +<para +>Ich habe einen Prototyp für ein Videostreaming-Programm implementiert, man kann ihn von <ulink url="http://space.twc.de/~stefan/kde/download/video-quickdraw.tar.gz" +>hier </ulink +> herunterladen. Er muss nach einigen Experimenten in &MCOP; integriert werden. </para> + +<para +>Eine Render-Komponente, die XMITSHM (mit <acronym +>RGB</acronym +> und <acronym +>YUV</acronym +>) unterstützt, sollte programmiert werden. Martin Vogt arbeitet derzeit an so etwas. </para> + +</sect1> + +<sect1 id="threading"> +<title +>Threading</title> + +<para +>Bisher ist &MCOP; Singel-Threaded. Für Video werden wir allerdings wohl nicht um Threading herum kommen. Dabei ist auf einige Dinge zu achten. </para> + + +<itemizedlist> +<listitem +><para +>SmartWrappers - sie sind nicht threadsicher wegen nicht abgesicherter Referenzzählung und ähnlichen Dingen. </para> +</listitem> +<listitem> +<para +>Dispatcher / I/O - nicht threadsicher. </para> +</listitem> +</itemizedlist> + +<para +>Ich könnte mir allerdings vorstellen, einzelne Modules sowohl für synchrones als auch asynchrone Streaming threadsicher zu machen. Auf diese Weise - mit einem threadtauglichen Flusssystem - könnte der Signalfluss auf zwei oder mehr Prozessoren verteilt werden. Damit wäre dem Audiosystem in Bezug auf Mehrprozessorsysteme erheblich geholfen. </para> + +<para +>Wie es funktionieren könnte: </para> + + +<itemizedlist> +<listitem> +<para +>Das Flusssystem entscheidet, welche Module was berechnen sollen - das sind: </para> + <itemizedlist> + <listitem +><para +>Video-Frames (mit der process_indata-Methode)</para +></listitem> + <listitem +><para +>Synchrone Audio-Ströme (calculateBlock)</para +></listitem> + <listitem +><para +>oder asynchrone Ströme, hauptsächlich Byte-Ströme</para +></listitem> + </itemizedlist> +</listitem> +<listitem> +<para +>Module können diese Dinge in eigenen Threads berechnen. Für Audio ist es sinnvoll, Threads wiederholt zu benutzen (z.B. rendern in vier Threads auf vier Prozessoren, unabhängig davon, ob 100 Module ausgeführt werden). Für Video und Byte-Dekomprimierung könnte es sinnvoll sein, eine blockierende Implementierung in einem eigenen Thread zu haben, der mit dem Rest das &MCOP;-Systems durch das Flusssystem synchronisiert wird. </para> +</listitem> + +<listitem> +<para +>Module dürfen die Funktionen von &MCOP; (wie entfernte Aufrufe) während Thread-Operationen nicht verwenden </para> +</listitem> +</itemizedlist> + +</sect1> + +<sect1 id="synchronization"> +<title +>Synchronisation</title> + +<para +>Video und &MIDI; (und Audio) müssen möglicherweise synchronisiert werden. Das funktioniert über Zeitmarken. Zeitmarken könnten zu asynchronen Strömen hinzugefügt werden, indem jedes Paket mit einer Zeitmarke versehen wird. Zwei Video-Frames müssen also als zwei Pakete gesendet werden (sie sind sowieso recht groß), damit sie unterschiedliche Zeitmarken haben können. </para> + +<para +>Audio sollte implizit Zeitmarken haben, da Audiodaten synchron wiedergegeben werden. </para> + +</sect1> + +<sect1 id="dynamic-composition"> +<title +>Dynamische Zusammenstellung (Composition)</title> + +<para +>Es sollte folgendes möglich sein: Ein FX-Effekt ist zusammengesetzt aus mehreren einfachen Modulen. Ein FX-Effekt sollte aussehen wie ein normales &MCOP;-Modul (siehe auch Maskierung (masquerading)), obwohl er aus anderen Modulen besteht. </para> + +<para +>Das ist für &arts-builder; erforderlich. </para> + +</sect1> + +<sect1 id="gui"> +<title +>&GUI;</title> + +<para +>Alle &GUI;-Komponenten werden &MCOP;-Module sein. Sie sollten Attribute wie Größe (size), Name (label), Farbe (color), ... haben. Ein <acronym +>RAD</acronym +>-Builder (&arts-builder;) sollte in der Lage sein, sie visuell zusammenzusetzen. </para> + +<para +>Das &GUI; sollte durch Sicherung der Attribute speicherbar sein. </para> + +</sect1> + +<sect1 id="midi-stuff"> +<title +>&MIDI;</title> + +<para +>&MIDI; sollte als asynchroner Strom implementiert werden. Es sollte zwei Möglichkeiten geben, zum Einen die Verwendung von normalen &MCOP;-Strukturen für die Typen und zum Anderen die Einführung von weiteren angepassten Typen. </para> + +<para +>Normale Strukturen sollten ausreichen, also etwas wie: </para> + +<programlisting +>struct MidiEvent { + byte b1,b2,b3; + sequence<byte> sysex; +} +</programlisting> + +<para +>Asynchrone Ströme sollten angepasste Typen unterstützen. </para> + +</sect1> + +</chapter> + + diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/glossary.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/glossary.docbook new file mode 100644 index 00000000000..3d5b1882607 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/glossary.docbook @@ -0,0 +1,173 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE glossary PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<glossary id="glossary"> + +<glossentry id="gloss-alsa"> +<glossterm +><acronym +>ALSA</acronym +></glossterm> +<glossdef> +<para +>Advanced &Linux; Sound Architecture; ein &Linux;-Soundkartentreiben, der aktuell nicht Bestandteil des Standard-Kernel-Quelltextes ist. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-arts"> +<glossterm +>&arts;</glossterm> +<glossdef> +<para +>Analog-Real-Time Synthesizer, der Name der Multimedia-Architektur/der Multimedia-Bibliothek/des Multimedia-Werkzeuges, das vom &kde;-Projekt verwendet wird (beachten Sie die Großschreibung) </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-bsd"> +<glossterm +><acronym +>BSD</acronym +></glossterm> +<glossdef> +<para +>Berkeley Software Distribution; bezieht sich auf jedes von einigen freien&UNIX;-kompatiblen Betriebssystemen, die von <acronym +>BSD</acronym +> &UNIX; abstammen. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-corba"> +<glossterm +><acronym +>CORBA</acronym +></glossterm> +<glossdef> +<para +>Common Object Request Broker Architecture;, ein Standard für objektorientierte entfernte Programmausführung. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-cvs"> +<glossterm +><acronym +>CVS</acronym +></glossterm> +<glossdef> +<para +>Concurrent Versions System;, ein Software-Managementsystem, das von vielen Softwareprojekten einschließlich &kde; und &arts; verwendet wird. </para> +</glossdef> +</glossentry> + +<glossentry id="glos-fft"> +<glossterm +><acronym +>FFT</acronym +></glossterm> +<glossdef> +<para +>Fast Fourier Transformation, ein Algorithmus, um Daten aus dem Zeitraum in den Frequenzraum zu transformieren; das wird für Signalverarbeitung häufig benötigt. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-full-duplex"> +<glossterm +>Voll-Duplex</glossterm> +<glossdef> +<para +>Die Fähigkeit einer Soundkarte gleichzeitig Daten abzuspielen und aufzunehmen. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-gpl"> +<glossterm +><acronym +>GPL</acronym +></glossterm> +<glossdef> +<para +><acronym +>GNU</acronym +> General Public Lzenz, die von der Free Software Foundation festgelegt wurde für die Veröffentlichung von freier Software. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-gui"> +<glossterm +>&GUI;</glossterm> +<glossdef> +<para +>Graphische Benutzeroberfläche </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-idl"> +<glossterm +><acronym +>IDL</acronym +></glossterm> +<glossdef> +<para +>Interface Definition Language, ein programmiersprachenunabhängiges Format zur Definition von Schnittstellen (Methoden und Daten). </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-kde"> +<glossterm +>&kde;</glossterm> +<glossdef> +<para +>K Desktop Environment, ein Projekt zur Entwicklung einer freien graphischen Benutzeroberfläche für &UNIX;-kompatible Systeme. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-lgpl"> +<glossterm +><acronym +>LGPL</acronym +></glossterm> +<glossdef> +<para +><acronym +>GNU</acronym +> Lesser General Public Lizenz, eine Programmlizenz, die von der Free Software Foundation aufgeschrieben wurde, um die Bedingungen für die Veröffentlichung von freier Software festzulegen. Sie ist weniger restriktiv als die <acronym +>GPL</acronym +> und wird häufig für Programmbibliotheken verwendet. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-mcop"> +<glossterm +>&MCOP;</glossterm> +<glossdef> +<para +>Multimedia COmmunication Protocol, das Protokoll, das für die Kommunikation der Teile von &arts; verwendet wird, ähnlich zu <acronym +>CORBA</acronym +>, aber einfacher und für Multimedia optimiert. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-midi"> +<glossterm +>&MIDI;</glossterm> +<glossdef> +<para +>Musical Instrument Digital Interface, ein Standardprotokoll zur Kommunikation von elektronischen Musikinstrumenten, häufig auch das Dateifomat zur Speicherung von &MIDI;-Befehlen. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-oss"> +<glossterm +><acronym +>OSS</acronym +></glossterm> +<glossdef> +<para +>Open Sound System, die Soundtreiber, die zum &Linux;-Kernel gehören (manchmal auch <acronym +>OSS</acronym +>/Free) oder eine kommerzielle Version, die von 4Front Technologies vertrieben werden. </para> +</glossdef> +</glossentry> + +</glossary> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/gui.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/gui.docbook new file mode 100644 index 00000000000..b769c161b6b --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/gui.docbook @@ -0,0 +1,29 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<!-- +<chapter id="gui-elements"> +<title +>&GUI; Elements</title> + +<sect1 id="gui-introduction"> +<title +>Introduction</title> + +</sect1> + +<sect1 id="parents"> +<title +>Parents</title> + +</sect1> + +<sect1 id="mixers"> +<title +>Mixers</title> + +</sect1> +</chapter> +--> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook new file mode 100644 index 00000000000..bc8f518eb16 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/helping.docbook @@ -0,0 +1,237 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="contributing"> +<title +>&arts; unterstützen</title> + +<sect1 id="how-to-help"> +<title +>Wie Sie helfen können</title> + +<para +>Das &arts;-Projekt benötigt einerseite Hilfe von Entwicklern, um existierende Multimedia-Anwendungen für &arts; anzupassen, neue Anwendungen zu schreiben und die Möglichkeiten von &arts; zu erweitern. Andererseits gibt es auch viele Aufgaben, die von Anderen übernommen werden können. Es werden Tester benötigt, die Fehlermeldungen liefern, Übersetzer, die die Anwendungstexte und die Dokumentation in andere Sprachen übersetzen, Graphiker, die Bitmaps (besonders für die <application +>artsbuilder</application +>-Module) entwerfen, Musiker, die Beispiele für &arts; erzeugen, und Autoren, die die Dokumentation schreiben und korrigieren. </para> +</sect1> + +<sect1 id="mailing-lists"> +<title +>Mailinglisten</title> + +<para +>Viele Diskussionen zur Entwicklung von &arts; finden in einer von zwei Mailinglisten statt. Hier werden neue Fähigkeiten und Umsetzungsideen diskutiert, hierhin kann man sich bei Problemen wenden. </para> + +<para +>Die &kde;-Multimedia-Mailingliste ist für allgemeine Multimediathemen sowohl &arts; als auch andere Multimediaprogramme wie &noatun; und &aktion; betreffend. Sie können sich auf der Internetseite <ulink url="http://www.kde.org/mailinglists.html" +>http://www.kde.org/mailingslists.html</ulink +> oder durch eine E-Mail mit dem Betreff (subject) <userinput +>subscribe <replaceable +>Ihre-E-Mail-Adresse</replaceable +></userinput +> an <email +>kde-multimedia-request@kde.org</email +> anmelden. Die Liste wird unter <ulink url="http://lists.kde.org" +>http://lists.kde.org</ulink +> archiviert. </para> + +<para +>In der &arts;-Mailingliste geht es um &arts;-spezifische Themen einschließlich der Nutzung von &arts; außerhalb von &kde;. Zur Anmeldung senden Sie eine E-Mail mit dem Inhalt <userinput +>subscribe <replaceable +>Ihre-E-Mail-Adresse</replaceable +></userinput +> an <email +>arts-request@space.twc.de</email +>. Die Liste wird unter <ulink url="http://space.twc.de/~stefan/arts-archive" +> http://space.twc.de/~stefan/arts-archive</ulink +> archiviert. </para> + +</sect1> + +<sect1 id="coding-standards"> +<title +>Programmierstandards (in Englisch)</title> + +<para +>For getting a consistent reading through all the sources, it is important to keep the coding style the same, all over the &arts; source. Please, even if you just write a module, try to write/format your source accordingly, as it will make it easier for different people to maintain the source tree, and easier to copy pieces of from one source to another. </para> + +<variablelist> +<varlistentry> +<term +>Naming of member functions</term> +<listitem> +<para +>&Qt;/&Java; style, that means capitalization on word breaks, and first letter always without capitalization; no underscores. </para> +<para +>This means for instance:</para> + +<programlisting +>createStructureDesc() + updateWidget(); + start(); </programlisting> + +</listitem> +</varlistentry> + +<varlistentry> +<term +>Class members</term> +<listitem> +<para +>Class members are not capitalized, such as menubar or button. </para> + +<para +>When there are accessing functions, the standard should be the &MCOP; way, that is, when having an long member <function +>foo</function +>, which shouldn't be visible directly, you create: </para> + +<programlisting +>foo(long new_value); + long foo(); </programlisting> + +<para +>functions to get and set the value. In that case, the real value of <function +>foo</function +> should be stored in <returnvalue +>_foo</returnvalue +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Class names</term> +<listitem> +<para +>All classes should be wordwise capitalized, that means <classname +>ModuleView</classname +>, <classname +>SynthModule</classname +>. All classes that belong to the libraries should use the &arts; namespace, like <classname +>Arts::Soundserver</classname +>. </para> +<para +>The implementations of &MCOP; classes should get called <classname +>Class_impl</classname +>, such as <classname +>SoundServer_impl</classname +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Parameters</term> +<listitem> +<para +>Parameters are always uncapitalized. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Local variables</term> +<listitem> +<para +>Local variables are always uncapitalized, and may have names like <varname +>i</varname +>, <varname +>p</varname +>, <varname +>x</varname +>, &etc; where appropriate. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Tab width (Shift width)</term> +<listitem> +<para +>One tab is as long as 4 spaces. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Leerzeichen in Ausdrücken</term> +<listitem> +<para +>Normalerweise müssen in Ausdrücken keine Leerzeichen verwendet werden. Man kann sie allerdings zwischen Operatoren und ihren Operanden setzen. Falls man allerdings ein Leerzeichen direkt vor einen Operator (wie z.B. +) setzt, muss man auch nach dem Operator ein Leerzeichen setzen. Die einzige Ausnahme von dieser Regel bilden listenartige Ausdrücke (mit ,), bei denen man nur hinter dem "," ein Leerzeichen setzen darf. Man kann es aber auch weglassen. </para> +<para +>Die folgenden Beispiele demonstrieren die sinnvolle Verwendung von Leerzeichen: </para> +<programlisting +>{ + int a,b; + int c, d, e; + int f = 4; + + a=b=c=d+e+f; + a = b = c = d + e + f; + + if(a == 4) { + a = b = c = (d+e)/2; + } + + while(b<3) + c--; + + arts_debug("%d\n", c); +} +</programlisting> +<para +>Die folgenden Beispiele demonstrieren, wie Leerzeichen <emphasis +>nicht</emphasis +> verwendet werden dürfen. Bei Funktionsaufrufen, nach "if", "for", "switch" und so weiter dürfen keine Leerzeichen stehen. </para> +<programlisting +>{ + // FALSCH: In einer Liste dürfen Leerzeichen nur nach dem "," stehen + int a , b , c , d , e , f; + + // FALSCH: unsymmetrische Leerzeichen beim =-Operator + a= 5; + + // FALSCH: "if" ist eine Funktion, daher dürfen keine Leerzeichen folgen + if (a == 5) { + } + + // FALSCH: nach "while" darf kein Leerzeichen folgen + while (a--) + b++; + + // FALSCH: Auf Funktionsnamen dürfen keine Leerzeichen folgen + arts_debug ("%d\n", c); + + // FALSCH: keines von beiden ist ein member-Name + Arts::Object o = Arts::Object::null (); +} +</programlisting> +</listitem> +</varlistentry> + + +<varlistentry> +<term +>Naming of source files</term> +<listitem> +<para +>Source files should have no capitalization in the name. They should have the name of the class when they implement a single class. Their extension is <literal role="extension" +>.cc</literal +> if they refer to &Qt;/&GUI; independent code, and <literal role="extension" +>.cpp</literal +> if they refer to &Qt;/&GUI; dependant code. Implementation files for interfaces should be called <filename +><replaceable +>foo</replaceable +>_impl</filename +>, if Foo was the name of the interface. </para> + +<para +>&IDL; files should be called in a descriptive way for the collection of interfaces they contain, also all lower case. Especially it is not good to call an &IDL; file like the class itself, as the .mcopclass trader and type info entries will collide, then. </para> +</listitem> +</varlistentry> +</variablelist> +</sect1> + +</chapter> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/index.cache.bz2 b/tde-i18n-de/docs/tdemultimedia/artsbuilder/index.cache.bz2 Binary files differnew file mode 100644 index 00000000000..fb40e844f40 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/index.cache.bz2 diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/index.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/index.docbook new file mode 100644 index 00000000000..66193b3a38a --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/index.docbook @@ -0,0 +1,417 @@ +<?xml version="1.0" ?> +<!DOCTYPE book PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd" [ + <!ENTITY kappname "&arts;"> + <!ENTITY tools SYSTEM "tools.docbook"> + <!ENTITY artsbuilder-doc SYSTEM "artsbuilder.docbook" +> + <!ENTITY detail SYSTEM "detail.docbook"> + <!ENTITY arts-midi SYSTEM "midi.docbook"> + <!ENTITY gui SYSTEM "gui.docbook"> + <!ENTITY mcop-ref SYSTEM "mcop.docbook"> + <!ENTITY arts-mcop SYSTEM "mcop.docbook"> + <!ENTITY apis SYSTEM "apis.docbook"> + <!ENTITY modules SYSTEM "modules.docbook"> + <!ENTITY porting SYSTEM "porting.docbook"> + <!ENTITY helping SYSTEM "helping.docbook"> + <!ENTITY future SYSTEM "future.docbook"> + <!ENTITY references SYSTEM "references.docbook"> + <!ENTITY arts-faq SYSTEM "faq.docbook"> + <!ENTITY arts-glossary SYSTEM "glossary.docbook"> + <!ENTITY digitalaudio SYSTEM "digitalaudio.docbook"> + <!ENTITY midiintro SYSTEM "midiintro.docbook"> + <!ENTITY MCOP "<acronym +>MCOP</acronym +>"> + <!ENTITY DCOP "<acronym +>DCOP</acronym +>"> + <!ENTITY MIDI "<acronym +>MIDI</acronym +>"> + <!ENTITY mcopidl "<application +>mcopidl</application +>"> + <!ENTITY IDL "<acronym +>IDL</acronym +>"> + <!ENTITY % German "INCLUDE" +> <!-- change language only here --> + <!ENTITY % addindex "IGNORE"> +]> + +<book lang="&language;"> +<bookinfo> +<title +>Das Handbuch zu &arts;</title> +<authorgroup> + +<author +><firstname +>Stefan</firstname +> <surname +>Westerfeld</surname +> <affiliation +> <address +><email +>stefan@space.twc.de</email +></address> +</affiliation> +</author> + +<author +><firstname +>Jeff</firstname +> <surname +>Tranter</surname +> <affiliation +> <address +><email +>tranter@kde.org</email +></address> +</affiliation> +</author> + +<othercredit role="translator" +><firstname +>Frank</firstname +><surname +>Schütte</surname +><affiliation +><address +><email +>F.Schuette@t-online.de</email +></address +></affiliation +><contrib +>Übersetzung</contrib +></othercredit +> +</authorgroup> + +<copyright> +<year +>1999-2001</year> +<holder +>Stefan Westerfeld & Jeff Tranter</holder> +</copyright> +<legalnotice +>&FDLNotice;</legalnotice> + +<date +>2001-06-10</date> +<releaseinfo +>1.00.09</releaseinfo> + +<abstract +><para +>Dieses Handbuch beschreibt &arts;, den analogen Echtzeit-Synthesizer.</para> + +</abstract> + +<keywordset> +<keyword +>aRts</keyword> +<keyword +>artsbuilder</keyword> +<keyword +>Synthesizer</keyword> +<keyword +>Multimedia</keyword> +<keyword +>Struktur</keyword> +<keyword +>Musik</keyword> +<keyword +>Klänge</keyword> +<keyword +>KDE</keyword> +</keywordset> +</bookinfo> + +<chapter id="introduction"> +<title +>Einleitung</title> + +<sect1 id="what-is-arts"> +<title +>Was ist &arts;?</title> + +<para +>Der analoge Echtzeit-Synthesizer (&arts;) ist ein modulares System zur Synthetisierung von Klängen und Musik auf einem Computer. Mit Hilfe von kleinen Bausteinen namens Modulen kann der Benutzer leicht komplexe Audio-Werkzeuge zusammenstellen. Module stellen typische Funktionen wie Hüllkurvengeneratoren, Filter, Audioeffekte, Mixer und Wiedergabe digitaler Klänge in verschiedenen Dateiformaten zur Verfügung.</para> + +<para +>Der &artsd; Soundserver mixt Klänge aus unterschiedlichen Quellen in Echtzeit. Damit können sich verschiedene Anwendungen transparent die zur Verfügung stehende Hardware teilen.</para> + +<para +>Durch Verwendung von &MCOP;, dem Multimedia-Kommunikationsprotokoll, können Multimediaprogramme netzwerktransparent (aus Sicherheitsgründen mit Authentifizierung) und plattformübergreifend durch die Verwendung von Schnittstellen programmiert werden, die sprachunabhängig mit Hilfe von &IDL; festgelegt werden können. Es gibt auch eine Unterstützung für sonstige und älter Anwendungen, die nicht &arts; verwenden. &arts; stellt einen Kernbestandteil der &kde; 2-Umgebung dar und ist die Basis der &kde;-Multimedia-Architektur. &arts; wird zukünftig noch weitere Medien unterstützen, unter anderem Video. Wie auch &kde;, kann &arts; auf einigen Betriebssystemen, einschließlich &Linux; und BSD-Varianten eingesetzt werden. &arts; kann auch unabhängig von &kde; verwendet werden.</para> + +</sect1> + +<sect1 id="using-this-manual"> +<title +>Verwendung dieses Dokuments</title> + +<para +>Dieses Dokument ist eine umfassende Dokumentation für Benutzer unterschiedlicher Vorkenntnisse für &arts;. Falls Sie ein gelegentlicher Nutzer von Multimediaprogrammen sind, sollten Sie einen anderen Weg durch dieses Dokument wählen als ein Entwickler von &arts;-Anwendungen.</para> + +<para +>Sie sollten zuerst den Abschnitt <link linkend="installation" +>Herunterladen und Kompilieren von &arts;</link +> lesen, falls Sie &arts; installieren möchten. Sollten Sie bereits ein funktionierendes System haben (häufig als Teil ihrer Distribution) können Sie diesen Abschnitt überspringen.</para> + +<para +>Als nächstes sollten Sie die Abschnitte unter <link linkend="arts-tools" +>&arts;-Werkzeuge</link +>, besonders &artsd;, &artscontrol;, &artsshell; und &artsdsp; lesen. Diese Abschnitte helfen Ihnen bei der optimalen Nutzung von &arts;.</para> + +<para +>Wenn Sie weitergehende Arbeiten mit &arts; planen, lesen Sie das Kapitel über <link linkend="artsbuilder" +>&arts-builder;</link +> und überfliegen Sie die Schritt-für-Schritt-Einführung. Das sollte Ihnen einen Eindruck der großen Möglichkeiten von &arts; und den ohne Programmierung nutzbaren Modulen geben.</para> + +<para +>Wenn Sie mehr über die internen Details von &arts; wissen möchten, weil Sie Multimedia-Anwendungen programmieren oder &arts; erweitern wollen, lesen Sie einiges oder alles aus dem Kapitel <link linkend="arts-in-detail" +>&arts; Details</link +>. Das sollte Ihnen ein Verständnis der Konzepte von &arts; ermöglichen, die für eine erfolgreiche Programmentwicklung notwendig sind.</para> + +<para +>Wenn Sie besonders an den <acronym +>MIDI</acronym +>-Fähigkeiten von &arts; interessiert sind, sollten Sie das Kapitel <link linkend="midi" +>&MIDI;</link +> lesen.</para> + +<!-- TODO +<para +>To learn more about the &arts; graphical elements, either as an advanced +user of artsbuilder or to create new elements, read the section on <link +linkend="gui-elements" +><acronym +>GUI</acronym +> Elements</link +>.</para> +--> + +<para +>Falls Sie planen &arts;-kompatible Multimedia-Anwendungen zu programmieren, lesen Sie das Kapitel <link linkend="arts-apis" +>&arts; Anwendungsprogramm-Schnittstellen</link +>, das die verschiedenen <acronym +>APIs</acronym +>detailiert beschreibt.</para> + +<para +>Wenn Sie &arts; durch neue Module erweitern wollen, lesen Sie das Kapitel <link linkend="arts-modules" +>&arts;-Module</link +>.</para> + +<para +>Falls Sie eine Anwendung ändern wollen, sodass Sie mit &arts; zusammenarbeitet, lesen Sie das Kapiteln <link linkend="porting" +>Anwendungen für &arts; portieren</link +>.</para> + +<para +>Wie Sie Beiträge zu &arts; leisten können, erfahren Sie im Kapitel <link linkend="contributing" +>Zu &arts; beitragen</link +>. Die zukünftige Planung für &arts; erfahren Sie im Kapitel <link linkend="future-work" +>Zukünftige Arbeiten</link +>. Dort finden Sie auch Verknüpfungen zu weiteren <link linkend="references" +>Informationen</link +>.</para> + +<para +>Wir haben das Hanbuch mit einigem Zusatzmaterial abgerundet: Das sind im Einzelnen <link linkend="faq" +>Antworten auf häufig gestellte Fragen</link +>, eine <link linkend="contributors" +>Liste der Mitarbeiter</link +>, detailierte Informationen zu <link linkend="copyright-and-licenses" +>Copyright und Lizenz</link +> von &arts; und einige Hintergrundinformationen zu <link linkend="intro-digital-audio" +>digitalem Audio</link +> und <link linkend="midi-introduction" +>&MIDI;</link +>. Weiterhin ist ein <link linkend="glossary" +>Glossar</link +> der verwendeten Begriffe enthalten.</para> + +<note> +<para +>Dieses Handbuch ist noch keineswegs vollständig. Falls Sie Teile hinzufügen möchten, sind Sie sehr willkommen. Kontaktieren Sie in diesem Fall zuerstt Jeff Tranter <email +>tranter@kde.org</email +> oder Stefan Westerfeld <email +>stefan@space.twc.de</email +>, um Dopplungen zu vermeiden. </para> +</note> + +</sect1> + +<sect1 id="history"> +<title +>Entwicklungsgeschichte</title> + +<para +>Spät im Jahre 1997 begann Stefan Westerfeld mit der Arbeit an einem modularen Echtzeit-System zur Klang-Synthese. Das Programm war ursprünglich für einen Power-PC unter &AIX; bestimmt. Die erste Version war einfach, unterstützte aber ein vollständiges Flusssystem, das solche Aufgaben wie die Wiedergabe einer MP3-Datei oder das Durchleiten eines Audio-Datenstroms durch Effektmodule durchführen konnte. </para> + + +<para +>Der nächste Schritt war die Implementation eines &GUI;, so dass die Modules grafisch bearbeitet werden konnten. Stefan hatte einige Erfahrung mit &kde; und diese Umgebung wurde daher als &GUI;-System (in dem Bewußtsein, das eine GNOME/Gtk+-Version ebenfalls erforderlich sein könnte) benutzt. Später führte das dazu, das &Linux; die Hauptentwicklungsplattform wurde. Vom ursprünglichen Namen <application +>ksynth</application +> wurde das Projekt in &arts; umbenannt und die Entwicklungsgeschwindigkeit nahm zu. Das Projekt war zu dieser Zeit mit einem <acronym +>CORBA</acronym +>-basierten Protokoll, dutzenden von Modulen, einem grafischen Moduleditor, C- und C++-<acronym +>API</acronym +>-Dokumentation, Hilfsprogrammen und einer Mailingsliste und Internetseite mit einer kleinen Entwicklergruppe bereits recht vollständig. Diese ganze Entwicklung fand in der sehr kurzen Zeit von nur einem Jahr statt.</para> + +<para +>Bei der Planung von &kde; 2.0 wurde es dem &kde;-Team klar, das &kde; eine bessere Klanginfrastruktur und Unterstützung für Klänge und andere Stream-Medien benötigte. Man entschied sich, &arts; für diese Zwecke anzupassen, da bereits eine fundierte Architektur vorhanden war. Es wurde große Mühe in eine neue Version von &arts; investiert, die umfangreichtse Entwicklung war die Ersetzung des <acronym +>CORBA</acronym +>-Protokolls durch ein völlig neues Subsystem mit dem Namen &MCOP;, das für Multimedia optimiert ist. Die Version 0.4 von &arts; wurde Bestandteil der Version 2.0 von &kde;.</para> + +<para +>Die Arbeit an &arts; geht weiter. Die Arbeitsgeschwindigkeit wird verbessert und neue Funktionen werden hinzugefügt. Obwohl &arts; ein Kernbestandteil von &kde; ist, kann es auch ohne &kde; verwendet werden. Es findet auch Verwendung in Anwendungen, die über das traditionelle Multimedia hinausgehen. Das Projekt hat auch beim GNOME-Team einiges Interesse hervorgerufen, so dass die Möglichkeit besteht, das es eines Tages die Standard-Multimedia-Architektur für &UNIX;-Arbeitsplatzrechner wird.</para> + +</sect1> + +</chapter> + +&tools; +&artsbuilder-doc; +&detail; +&arts-midi; +&gui; +&mcop-ref; +&apis; +&modules; +&porting; +&helping; +&future; +&references; +&arts-faq; + +<chapter id="copyright-and-licenses"> + +<title +>&arts; Copyright und Lizensierung</title> + +<para +>&arts; Programm-Copyright 1998-2001 Stefan Westerfeld <email +>stefan@space.twc.de</email +></para> + +<para +><anchor id="contributors"/> Dokumentation Copyright 1999-2001 Stefan Westerfeld <email +>stefan@space.twc.de</email +> und Jeff Tranter <email +>tranter@kde.org</email +>. </para> +<para +>Übersetzung: Frank Schütte <email +>F.Schuette@t-online.de</email +></para +> +&underFDL; <para +>Alle Bibliotheken in &arts; stehen unter der <acronym +>GNU</acronym +> Lesser General Public Lizenz. Die überwiegende Menge des &arts;-Programms befindet sich in den Bibliotheken, einschließlich des gesamten <acronym +>MCOP</acronym +> und ArtsFlow. Damit können die Bibliotheken auch für nicht-freie/nicht-offene Anwendungen verwendet werden, falls gewünscht. </para> + +<para +>Es gibt einige Programme (wie <application +>artsd</application +>), die unter der <acronym +>GNU</acronym +> General Public Lizenz stehen. Da es unterschiedliche Einstellungen dazu gibt, ob es erlaubt ist, <acronym +>GPL</acronym +>-Anwendungen mit &Qt; zu linken, habe ich dieses explizit erlaubt, also zusätzlich zur <acronym +>GPL</acronym +>: Es ist auch erlaubt, dieses Programm mit der &Qt;-Bibliothek zu linken; dabei wird &Qt; wie eine Bibliothek benutzt, die normalerweise zu einem Betriebssystem dazugehört, ob das im Einzelfall so ist oder nicht (hier noch der Originaltext: "permission is also granted to link this program with the Qt library, treating Qt like a library that normally accompanies the operating system kernel, whether or not that is in fact the case.")</para> + +</chapter> + +<appendix id="installation"> +<title +>&arts; installieren</title> + +<para +>Um &arts; benutzen zu können, müssen Sie es zuerst installieren und starten. Dazu gibt es zwei Möglichkeiten, die in den nächsten beiden Abschnitten beschrieben werden. </para> + +<sect1 id="binary-install"> +<title +>Ein vorkompiliertes Binärpaket installieren</title> + +<para +>Der schnellste und einfachste Weg, um &arts; auf Ihrem System zu installieren ist ein vorkompiliertes Binärpaket. Aktuelle Versionen von &Linux;-Distributionen beinhalten &kde;, und wenn es sich um &kde; 2.0 oder später handelt, enthalten Sie &arts;. Wenn &kde; nicht in Ihrer Distribution enthalten ist, können Sie sie vielleicht von Ihrem Händler herunterladen. Alternativ sind manche Binärpakete auch von dritter Seite erhältlich. Achten Sie darauf, das die verwendeten Pakete kompatibel mit Ihrer Betriebssystemversion sind. </para> + +<para +>Eine grundlegende Installation von &kde; enthält den Soundserver, damit die meisten Anwendungen Klänge abspielen können. Wenn Sie das gesamte Paket der Multimedia-Werkzeuge und -Anwendungen haben wollen, müssen Sie vermutlich noch einige optionale Pakete installieren. </para> + +<para +>Der Nachteil an vorkompilierten Binärpaketen ist, das sie vermutlich nicht die aktuellste Version von &arts; enthalten. Das ist noch wahrscheinlicher, wenn Sie auf &CD-ROM; bereitstehen, da die Entwicklungsgeschwindigkeit von &arts; und &kde; so groß ist, das Medien wie die &CD-ROM; in der Regel nicht mithalten können. Sie werden auch feststellen, das, wenn Sie eine ungebräuchliche Distribution oder eine ungewöhnliche Konfiguration haben, Binärpakete nicht verfügbar sind. In solchen Fällen sind Sie auf die zweite Methode angewiesen. </para> + +</sect1> + +<sect1 id="source-install"> +<title +>Erstellen aus den Quelltexten</title> + +<para +>Der zeitaufwendigste aber flexibelste Weg ist, &arts; aus den Quelltexten selbst zu kompilieren. Das sichert, dass die kompilierte Version optimal für Ihre Systemeinrichtung geeignet ist und erlaubt Ihnen, die jeweils aktuelle Version zu verwenden. </para> + +<para +>Sie haben zwei Möglichkeiten -- entweder Sie installieren die letzte stabile Version, die zu &kde; gehört, oder Sie nehmen die aktuellste (aber vielleicht instabile) Version direkt aus dem <acronym +>CVS</acronym +>-Repository des &kde;-Projektes. Die meisten Benutzer, die nicht für &arts; entwickeln, sollten die stabile Version verwenden. Sie können sie von <ulink url="ftp://ftp.kde.org" +>ftp://ftp.kde.org</ulink +> oder von einem der vielen Mirrors herunterladen. Wenn Sie für &arts; entwickeln, sollten Sie die <acronym +>CVS</acronym +>-Version verwenden. Wenn Sie aRts ohne KDE verwenden wollen, können Sie einen selbstständigen Entwicklugsschnappschuß (Snapshot) von <ulink url="http://space.twc.de/~stefan/kde/arts-snapshot-doc.html" +> http://space.twc.de/~stefan/kde/arts-snapshot-doc.html</ulink +> herunterladen. </para> + +<para +>Weiterhin gilt, wenn Sie aus dem <acronym +>CVS</acronym +> kompilieren, es befinden sich einige Komponenten von &arts; (&dh; die grundlegenden Komponenten einschließlich des Soundservers) in dem <acronym +>CVS</acronym +>-Modul tdelibs, während weitere Komponenten (&zb; <application +>artsbuilder</application +>) sich im Modul tdemultimedia befinden. Das kann sich in Zukunft ändern. Im Modul kmusic finden Sie ebenfalls ein Version; es handelt sich dabei um die alte (vor-&kde; 2.0) Version, die jetzt überholt ist. </para> + +<para +>Die Vorbedingungen für die Kompilierung von &arts; sind die gleichen wie für den Rest von &kde;. Die configure-Skripte sollten Ihr Sytem identifizieren und anzeigen, falls benötigte Komponenten fehlen. Vergewissern Sie sich, das Ihr Sound-Treiber funktioniert (entweder der <acronym +>OSS</acronym +>/Free Kerneltreiber, der <acronym +>OSS</acronym +>-Treiber von 4Front Technologies oder der <acronym +>ALSA</acronym +>-Treiber mit <acronym +>OSS</acronym +>-Emulation). </para> + +<para +>Weitere Informationen zum Herunterladen und installieren von &kde; (einschließlich &arts;) finden Sie in der <ulink url="http://www.kde.org/documentation/faq/index.html" +>&kde; &FAQ;</ulink +>.</para> + +</sect1> + +</appendix> + +&digitalaudio; +&midiintro; +&arts-glossary; + +</book> +<!-- +Local Variables: +mode: sgml +sgml-omittag:nil +sgml-shorttag:t +sgml-namecase-general:t +sgml-general-insert-case:lower +sgml-minimize-attributes:nil +sgml-always-quote-attributes:t +sgml-indent-step:0 +sgml-indent-data:nil +End: +--> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook new file mode 100644 index 00000000000..84e77bce7f3 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/mcop.docbook @@ -0,0 +1,1899 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.1.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="mcop"> +<title +>&MCOP;: Objekt Modell und Streaming</title> + +<sect1 id="mcop-overview"> + +<title +>Ãberblick</title> + +<para +> &MCOP; ist der Standard, den &arts; für folgende Aufgaben verwendet: </para> + +<itemizedlist +> <listitem +> <para +> Kommunikation zwischen Objekten. </para +> </listitem +> <listitem +> <para +> Netzwerk-Transparenz. </para +> </listitem +> <listitem +> <para +> Beschreibung von Objekt-Schnittstellen. </para +> </listitem +> <listitem +> <para +> Programmiersprachenunabhängigkeit. </para +> </listitem +> </itemizedlist> + +<para +> Ein wichtiger Aspekt von &MCOP; ist die <emphasis +> Interface Description Language</emphasis +> , &IDL;, in der viele der Schnittstellen (Interfaces) und <acronym +>API</acronym +>s von &arts; sprachunabhängig definiert worden sind. </para> + +<para +> &IDL;-Schnittstellen werden durch den &IDL;-Ãbersetzer in C++-Quelltexte übersetzt. Wenn Sie eine Schnittstelle implementieren, verwenden Sie als Grundlage das Klassenskelett, das der &IDL;-Ãbersetzer erstellt hat. Wenn Sie eine Schnittstelle verwenden, benutzen Sie einen Wrapper. Auf diese Weise kann &MCOP; ein Protokoll verwenden, wenn das Objekt, das Sie verwenden nicht lokal ist - Sie haben also volle Netzwerk-Transparenz. </para> + +<para +> Dieses Kapitel soll die grundlegenden Möglichkeiten des Objektmodells beschreiben, das durch die Verwendung von &MCOP;, das Protokoll selbst und seine Verwendung in C++ (Sprachbindung) entsteht. Dieses Kapitel wird nicht übersetzt, da zur Programmierung ohnehin englische Sprachkenntnisse unabdingbar sind. </para> + +</sect1> + +<sect1 id="interfaces"> + +<title +>Interfaces and &IDL;</title> + +<para +> Many of the services provided by &arts;, such as modules and the sound server, are defined in terms of <acronym +>interfaces</acronym +>. Interfaces are specified in a programming language independent format: &IDL;. </para> + +<para +> This allows many of the implementation details such as the format of multimedia data streams, network transparency, and programming language dependencies, to be hidden from the specification for the interface. A tool, &mcopidl;, translates the interface definition into a specific programming language (currently only C++ is supported). </para> + +<para +> The tool generates a skeleton class with all of the boilerplate code and base functionality. You derive from that class to implement the features you want. </para> + +<para +> The &IDL; used by &arts; is similar to that used by <acronym +>CORBA</acronym +> and <acronym +>DCOM</acronym +>. </para> + +<para +> &IDL; files can contain: </para> + +<itemizedlist +> <listitem +> <para +> C-style #include directives for other &IDL; files. </para +> </listitem +> <listitem +> <para +> Definitions of enumerated and struct types, as in C/C++. </para +> </listitem +> <listitem +> <para +> Definitions of interfaces. </para +> </listitem +> </itemizedlist> + +<para +> In &IDL;, interfaces are defined much like a C++ class or C struct, albeit with some restrictions. Like C++, interfaces can subclass other interfaces using inheritance. Interface definitions can include three things: streams, attributes, and methods. </para> + +<sect2 id="streams"> + +<title +>Streams</title> + +<para +> Streams define multimedia data, one of the most important components of a module. Streams are defined in the following format: </para> + +<para +> [ async ] in|out [ multi ] <replaceable +>type</replaceable +> stream <replaceable +>name</replaceable +> [ , <replaceable +>name</replaceable +> ] ; </para> + +<para +> Streams have a defined direction in reference to the module, as indicated by the required qualifiers in or out. The type argument defines the type of data, which can be any of the types described later for attributes (not all are currently supported). Many modules use the stream type audio, which is an alias for float since that is the internal data format used for audio stream. Multiple streams of the same type can defined in the same definition uisng comma separated names. </para> + +<para +> Streams are by default synchronous, which means they are continuous flows of data at a constant rate, such as <acronym +>PCM</acronym +> audio. The async qualifier specifies an asynchronous stream, which is used for non-continuous data flows. The most common example of an async stream is &MIDI; messages. </para> + +<para +> The multi keyword, only valid for input streams, indicates that the interface supports a variable number of inputs. This is useful for implementing devices such as mixers that can accept any number of input streams. </para> + +</sect2> +<sect2 id="attributes"> + +<title +>Attributes</title> + +<para +> Attributes are data associated with an instance of an interface. They are declared like member variables in C++, and can can use any of the primitive types boolean, byte, long, string, or float. You can also use user-defined struct or enum types as well as variable sized sequences using the syntax sequence<type>. Attributes can optionally be marked readonly. </para> + +</sect2> +<sect2 id="methods"> + +<title +>Methods</title> + +<para +> As in C++, methods can be defined in interfaces. The method parameters are restricted to the same types as attributes. The keyword oneway indicates a method which returns immediately and is executed asynchronously. </para> + +</sect2> + +<sect2 id="standardinterfaces"> + +<title +>Standard Interfaces</title> + +<para +> Several standard module interfaces are already defined for you in &arts;, such as <interfacename +>StereoEffect</interfacename +>, and <interfacename +>SimpleSoundServer</interfacename +>. </para> + +</sect2> + +<sect2 id="example"> +<title +>Example</title> + +<para +> A simple example of a module taken from &arts; is the constant delay module, found in the file <filename +>tdemultimedia/arts/modules/artsmodules.idl</filename +>. The interface definition is listed below. </para> + +<programlisting> +interface Synth_CDELAY : SynthModule { + attribute float time; + in audio stream invalue; + out audio stream outvalue; +}; +</programlisting> + +<para +> This modules inherits from <interfacename +>SynthModule</interfacename +>. That interface, defined in <filename +>artsflow.idl</filename +>, defines the standard methods implemented in all music synthesizer modules. </para> + +<para +> The CDELAY effect delays a stereo audio stream by the time value specified as a floating point parameter. The interface definition has an attribute of type float to store the delay value. It defines two input audio streams and two output audio streams (typical of stereo effects). No methods are required other than those it inherits. </para> + +</sect2> + +</sect1> + +<sect1 id="more-about-streams"> +<title +>More About Streams</title> + +<para +> This section covers some additional topics related to streams. </para> + +<sect2 id="stream-types"> +<title +>Stream Types</title> + +<para +> There are various requirements for how a module can do streaming. To illustrate this, consider these examples: </para> + +<itemizedlist +> <listitem +> <para +> Scaling a signal by a factor of two. </para +> </listitem +> <listitem +> <para +> Performing sample frequency conversion. </para +> </listitem +> <listitem +> <para +> Decompressing a run-length encoded signal. </para +> </listitem +> <listitem +> <para +> Reading &MIDI; events from <filename class="devicefile" +>/dev/midi00</filename +> and inserting them into a stream. </para +> </listitem +> </itemizedlist> + +<para +> The first case is the simplest: upon receiving 200 samples of input the module produces 200 samples of output. It only produces output when it gets input. </para> + +<para +> The second case produces different numbers of output samples when given 200 input samples. It depends what conversion is performed, but the number is known in advance. </para> + +<para +> The third case is even worse. From the outset you cannot even guess how much data 200 input bytes will generate (probably a lot more than 200 bytes, but...). </para> + +<para +> The last case is a module which becomes active by itself, and sometimes produces data. </para> + +<para +> In &arts;s-0.3.4, only streams of the first type were handled, and most things worked nicely. This is probably what you need most when writing modules that process audio. The problem with the other, more complex types of streaming, is that they are hard to program, and that you don't need the features most of the time. That is why we do this with two different stream types: synchronous and asynchronous. </para> + +<para +> Synchronous streams have these characteristics: </para> + +<itemizedlist +> <listitem +> <para +> Modules must be able to calculate data of any length, given enough input. </para +> </listitem +> <listitem +> <para +> All streams have the same sampling rate. </para +> </listitem +> <listitem +> <para +> The <function +>calculateBlock()</function +> function will be called when enough data is available, and the module can rely on the pointers pointing to data. </para +> </listitem +> <listitem +> <para +> There is no allocation and deallocation to be done. </para +> </listitem +> </itemizedlist> + +<para +> Asynchronous streams, on the other hand, have this behaviour: </para> + +<itemizedlist +> <listitem +> <para +> Modules may produce data sometimes, or with varying sampling rate, or only if they have input from some filed escriptor. They are not bound by the rule <quote +>must be able to satisfy requests of any size</quote +>. </para +> </listitem +> <listitem +> <para +> Asynchronous streams of a module may have entirely different sampling rates. </para +> </listitem +> <listitem +> <para +> Outgoing streams: there are explicit functions to allocate packets, to send packets - and an optional polling mechanism that will tell you when you should create some more data. </para +> </listitem +> <listitem +> <para +> Incoming streams: you get a call when you receive a new packet - you have to say when you are through with processing all data of that packet, which must not happen at once (you can say that anytime later, and if everybody has processed a packet, it will be freed/reused) </para +> </listitem +> </itemizedlist> + +<para +> When you declare streams, you use the keyword <quote +>async</quote +> to indicate you want to make an asynchronous stream. So, for instance, assume you want to convert an asynchronous stream of bytes into a synchronous stream of samples. Your interface could look like this: </para> + +<programlisting> +interface ByteStreamToAudio : SynthModule { + async in byte stream indata; // the asynchonous input sample stream + + out audio stream left,right; // the synchronous output sample streams +}; +</programlisting> + +</sect2> + +<sect2 id="async-streams"> +<title +>Using Asynchronous Streams</title> + +<para +> Suppose you decided to write a module to produce sound asynchronously. Its interface could look like this: </para> + +<programlisting> +interface SomeModule : SynthModule +{ + async out byte stream outdata; +}; +</programlisting> + +<para +> How do you send the data? The first method is called <quote +>push delivery</quote +>. With asynchronous streams you send the data as packets. That means you send individual packets with bytes as in the above example. The actual process is: allocate a packet, fill it, send it. </para> + +<para +> Here it is in terms of code. First we allocate a packet: </para> + +<programlisting> +DataPacket<mcopbyte> *packet = outdata.allocPacket(100); +</programlisting> + +<para +> The we fill it: </para> + +<programlisting> +// cast so that fgets is happy that it has a (char *) pointer +char *data = (char *)packet->contents; + +// as you can see, you can shrink the packet size after allocation +// if you like +if(fgets(data,100,stdin)) + packet->size = strlen(data); +else + packet->size = 0; +</programlisting> + +<para +> Now we send it: </para> + +<programlisting> +packet->send(); +</programlisting> + +<para +> This is quite simple, but if we want to send packets exactly as fast as the receiver can process them, we need another approach, the <quote +>pull delivery</quote +> method. You ask to send packets as fast as the receiver is ready to process them. You start with a certain amount of packets you send. As the receiver processes one packet after another, you start refilling them with fresh data, and send them again. </para> + +<para +> You start that by calling setPull. For example: </para> + +<programlisting> +outdata.setPull(8, 1024); +</programlisting> + +<para +> This means that you want to send packets over outdata. You want to start sending 8 packets at once, and as the receiver processes some of them, you want to refill them. </para> + +<para +> Then, you need to implement a method which fills the packets, which could look like this: </para> + +<programlisting> +void request_outdata(DataPacket<mcopbyte> *packet) +{ + packet->size = 1024; // shouldn't be more than 1024 + for(int i = 0;i < 1024; i++) + packet->contents[i] = (mcopbyte)'A'; + packet->send(); +} +</programlisting> + +<para +> Thats it. When you don't have any data any more, you can start sending packets with zero size, which will stop the pulling. </para> + +<para +> Note that it is essential to give the method the exact name <methodname +>request_<replaceable +>streamname</replaceable +></methodname +>. </para> + +<para +> We just discussed sending data. Receiving data is much much simpler. Suppose you have a simple ToLower filter, which simply converts all letters in lowercase: </para> + +<programlisting> +interface ToLower { + async in byte stream indata; + async out byte stream outdata; +}; +</programlisting> + +<para +> This is really simple to implement; here is the whole implementation: </para> + +<programlisting> +class ToLower_impl : public ToLower_skel { +public: + void process_indata(DataPacket<mcopbyte> *inpacket) + { + DataPacket<mcopbyte> *outpacket = outdata.allocPacket(inpacket->size); + + // convert to lowercase letters + char *instring = (char *)inpacket->contents; + char *outstring = (char *)outpacket->contents; + + for(int i=0;i<inpacket->size;i++) + outstring[i] = tolower(instring[i]); + + inpacket->processed(); + outpacket->send(); + } +}; + +REGISTER_IMPLEMENTATION(ToLower_impl); +</programlisting> + +<para +> Again, it is essential to name the method <methodname +>process_<replaceable +>streamname</replaceable +></methodname +>. </para> + +<para +> As you see, for each arriving packet you get a call for a function (the <function +>process_indata</function +> call in our case). You need to call the <methodname +>processed()</methodname +> method of a packet to indicate you have processed it. </para> + +<para +> Here is an implenetation tip: if processing takes longer (&dh; if you need to wait for soundcard output or something like that), don't call processed immediately, but store the whole data packet and call processed only as soon as you really processed that packet. That way, senders have a chance to know how long it really takes to do your work. </para> + +<para +> As synchronization isn't so nice with asynchronous streams, you should use synchronous streams wherever possible, and asynchronous streams only when necessary. </para> + +</sect2> + +<sect2 id="default-streams"> +<title +>Default Streams</title> + +<para +> Suppose you have 2 objects, for example an AudioProducer and an AudioConsumer. The AudioProducer has an output stream and AudioConsumer has an input one. Each time you want to connect them, you will use those 2 streams. The first use of defaulting is to enable you to make the connection without specifying the ports in that case. </para> + +<para +> Now suppose the teo objects above can handle stereo, and each have a <quote +>left</quote +> and <quote +>right</quote +> port. You'd still like to connect them as easily as before. But how can the connecting system know which output port to connect to which input port? It has no way to correctly map the streams. Defaulting is then used to specify several streams, with an order. Thus, when you connect an object with 2 default output streams to another one with 2 default input streams, you don't have to specify the ports, and the mapping will be done correctly. </para> + +<para +> Of course, this is not limited to stereo. Any number of streams can be made default if needed, and the connect function will check that the number of defaults for 2 object match (in the required direction) if you don't specify the ports to use. </para> + +<para +> The syntax is as follows: in the &IDL;, you can use the default keyword in the stream declaration, or on a single line. For example: </para> + +<programlisting> +interface TwoToOneMixer { + default in audio stream input1, input2; + out audio stream output; +}; +</programlisting> + +<para +> In this example, the object will expect its two input ports to be connected by default. The order is the one specified on the default line, so an object like this one: </para> + +<programlisting> +interface DualNoiseGenerator { + out audio stream bzzt, couic; + default couic, bzzt; +}; +</programlisting> + +<para +> Will make connections from <quote +>couic</quote +> to <quote +>input1</quote +>, and <quote +>bzzt</quote +> to <quote +>input2</quote +> automatically. Note that since there is only one output for the mixer, it will be made default in this case (see below). The syntax used in the noise generator is useful to declare a different order than the declaration, or selecting only a few ports as default. The directions of the ports on this line will be looked up by &mcopidl;, so don't specify them. You can even mix input and output ports in such a line, only the order is important. </para> + +<para +> There are some rules that are followed when using inheritance: </para> + +<itemizedlist +> <listitem +> <para +> If a default list is specified in the &IDL;, then use it. Parent ports can be put in this list as well, whether they were default in the parent or not. </para +> </listitem +> <listitem +> <para +> Otherwise, inherit parent's defaults. Ordering is parent1 default1, parent1 default2..., parent2 default1... If there is a common ancestor using 2 parent branches, a <quote +>virtual public</quote +>-like merging is done at that default's first occurrence in the list. </para +> </listitem +> <listitem +> <para +> If there is still no default and a single stream in a direction, use it as default for that direction. </para +> </listitem +> </itemizedlist> + +</sect2> + +</sect1> +<sect1 id="attribute-change-notify"> +<title +>Attribute change notifications</title> + +<!-- TODO: This should be embedded better into the context - I mean: the + context should be written ;-). --> + +<para +> Attribute change notifications are a way to know when an attribute changed. They are a bit comparable with &Qt;'s or Gtk's signals and slots. For instance, if you have a &GUI; element, a slider, which configures a number between 0 and 100, you will usually have an object that does something with that number (for instance, it might be controlling the volume of some audio signal). So you would like that whenever the slider is moved, the object which scales the volume gets notified. A connection between a sender and a receiver. </para> + +<para +> &MCOP; deals with that by being able to providing notifications when attributes change. Whatever is declared as <quote +>attribute</quote +> in the &IDL;, can emit such change notifications, and should do so, whenever it is modified. Whatever is declared as <quote +>attribute</quote +> can also receive such change notifications. So for instance if you had two &IDL; interfaces, like these: </para> + +<programlisting> + interface Slider { + attribute long min,max; + attribute long position; + }; + interface VolumeControl : Arts::StereoEffect { + attribute long volume; // 0..100 + }; +</programlisting> + +<para +> You can connect them using change notifications. It works using the normal flowsystem connect operation. In this case, the C++ code to connect two objects would look like this: </para> + +<programlisting> +#include <connect.h> +using namespace Arts; +[...] +connect(slider,"position_changed",volumeControl,"volume"); +</programlisting> + +<para +> As you see, each attribute offers two different streams, one for sending the change notifications, called <function +><replaceable +>attributename</replaceable +>_changed</function +>, and one for receiving change notifications, called <function +>attributename</function +>. </para> + +<para +> It is important to know that change notifications and asynchronous streams are compatible. They are also network transparent. So you can connect a change notification of a float attribute of a &GUI; widget has to an asynchronous stream of a synthesis module running on another computer. This of course also implies that change notifications are <emphasis +>not synchronous</emphasis +>, this means, that after you have sent the change notification, it may take some time until it really gets received. </para> + +<sect2 id="sending-change-notifications"> + +<title +>Sending change notifications</title> + +<para +> When implementing objects that have attributes, you need to send change notifications whereever an attribute changes. The code for doing this looks like this: </para> + +<programlisting> + void KPoti_impl::value(float newValue) + { + if(newValue != _value) + { + _value = newValue; + value_changed(newValue); // <- send change notification + } + } +</programlisting> + +<para +> It is strongly recommended to use code like this for all objects you implement, so that change notifications can be used by other people. You should however void sending notifications too often, so if you are doing signal processing, it is probably the best if you keep track when you sent your last notification, so that you don't send one with every sample you process. </para> + +</sect2> + +<sect2 id="change-notifications-apps"> +<title +>Applications for change notifications</title> + +<para +> It will be especially useful to use change notifications in conjunction with scopes (things that visualize audio data for instance), gui elements, control widgets, and monitoring. Code using this is in <filename class="directory" +>tdelibs/arts/tests</filename +>, and in the experimental artsgui implementation, which you can find under <filename class="directory" +>tdemultimedia/arts/gui</filename +>. </para> + +<!-- TODO: can I markup links into the source code - if yes, how? --> + +<!-- LW: Linking into the source is problematic - we can't assume people are +reading this on a machine with the sources available, or that they aren't +reading it from a website. We're working on it! --> + +</sect2> +</sect1> + +<sect1 id="the-mcoprc-file"> + +<title +>The <literal role="extension" +>.mcoprc</literal +> file</title> + +<para +> The <literal role="extension" +>.mcoprc</literal +> file (in each user's home directory) can be used to configure &MCOP; in some ways. Currently, the following is possible: </para> + +<variablelist +> <varlistentry +> <term +>GlobalComm</term +> <listitem +> <para +> The name of an interface to be used for global communication. Global communication is used to find other objects and obtain the secret cookie. Multiple &MCOP; clients/servers that should be able to talk to each other need to have a GlobalComm object which is able to share information between them. Currently, the possible values are <quote +>Arts::TmpGlobalComm</quote +> to communicate via <filename class="directory" +>/tmp/mcop-<replaceable +>username</replaceable +></filename +> directory (which will only work on the local computer) and <quote +>Arts::X11GlobalComm</quote +> to communicate via the root window properties on the X11 server. </para +> </listitem +> </varlistentry +> <varlistentry +> <term +>TraderPath</term +> <listitem +> <para +> Specifies where to look for trader information. You can list more than one directory here, and separate them with commas, like </para +> </listitem +> </varlistentry +> <varlistentry +> <term +>ExtensionPath</term +> <listitem +> <para +> Specifies from which directories extensions (in the form of shared libraries) are loaded. Multiple values can be specified comma seperated. </para +> </listitem +> </varlistentry +> </variablelist> + +<para +> An example which uses all of the above is: </para> + +<programlisting> +# $HOME/.mcoprc file +GlobalComm=Arts::X11GlobalComm + +# if you are a developer, it might be handy to add a directory in your home +# to the trader/extension path to be able to add components without +# installing them +TraderPath="/opt/kde2/lib/mcop","/home/joe/mcopdevel/mcop" +ExtensionPath="/opt/kde2/lib","/home/joe/mcopdevel/lib" +</programlisting> + +</sect1> + +<sect1 id="mcop-for-corba-users"> +<title +>&MCOP; for <acronym +>CORBA</acronym +> Users</title> + +<para +> If you have used <acronym +>CORBA</acronym +> before, you will see that &MCOP; is much the same thing. In fact, &arts; prior to version 0.4 used <acronym +>CORBA</acronym +>. </para> + +<para +> The basic idea of <acronym +>CORBA</acronym +> is the same: you implement objects (components). By using the &MCOP; features, your objects are not only available as normal classes from the same process (via standard C++ techniques) - they also are available to remote servers transparently. For this to work, the first thing you need to do is to specify the interface of your objects in an &IDL; file - just like <acronym +>CORBA</acronym +> &IDL;. There are only a few differences. </para> + +<sect2 id="corba-missing"> +<title +><acronym +>CORBA</acronym +> Features That Are Missing In &MCOP;</title> + +<para +> In &MCOP; there are no <quote +>in</quote +> and <quote +>out</quote +> parameters on method invocations. Parameters are always incoming, the return code is always outgoing, which means that the interface: </para> + +<programlisting> +// CORBA idl +interface Account { + void deposit( in long amount ); + void withdraw( in long amount ); + long balance(); +}; +</programlisting> + +<para +> is written as </para> + +<programlisting> +// MCOP idl +interface Account { + void deposit( long amount ); + void withdraw( long amount ); + long balance(); +}; +</programlisting> + +<para +> in &MCOP;. </para> + +<para +> There is no exception support. &MCOP; doesn't have exceptions - it uses something else for error handling. </para> + +<para +> There are no union types and no typedefs. I don't know if that is a real weakness, something one would desperately need to survive. </para> + +<para +> There is no support for passing interfaces or object references </para> + +</sect2> + +<sect2 id="corba-different"> +<title +><acronym +>CORBA</acronym +> Features That Are Different In &MCOP;</title> + +<para +> You declare sequences as <quote +>sequence<replaceable +>type</replaceable +></quote +> in &MCOP;. There is no need for a typedef. For example, instead of: </para> + +<programlisting> +// CORBA idl +struct Line { + long x1,y1,x2,y2; +}; +typedef sequence<Line> LineSeq; +interface Plotter { + void draw(in LineSeq lines); +}; +</programlisting> + +<para +> you would write </para> + +<programlisting> +// MCOP idl +struct Line { + long x1,y1,x2,y2; +}; +interface Plotter { + void draw(sequence<Line> lines); +}; +</programlisting> + +</sect2> + +<sect2 id="no-in-corba"> +<title +>&MCOP; Features That Are Not In <acronym +>CORBA</acronym +></title> + +<para +> You can declare streams, which will then be evaluated by the &arts; framework. Streams are declared in a similar manner to attributes. For example: </para> + +<programlisting> +// MCOP idl +interface Synth_ADD : SynthModule { + in audio stream signal1,signal2; + out audio stream outvalue; +}; +</programlisting> + +<para +> This says that your object will accept two incoming synchronous audio streams called signal1 and signal2. Synchronous means that these are streams that deliver x samples per second (or other time), so that the scheduler will guarantee to always provide you a balanced amount of input data (&zb; 200 samples of signal1 are there and 200 samples signal2 are there). You guarantee that if your object is called with those 200 samples signal1 + signal2, it is able to produce exactly 200 samples to outvalue. </para> + +</sect2> + +<sect2 id="mcop-binding"> +<title +>The &MCOP; C++ Language Binding</title> + +<para +> This differs from <acronym +>CORBA</acronym +> mostly: </para> + +<itemizedlist +> <listitem +> <para +> Strings use the C++ <acronym +>STL</acronym +> <classname +>string</classname +> class. When stored in sequences, they are stored <quote +>plain</quote +>, that means they are considered to be a primitive type. Thus, they need copying. </para +> </listitem +> <listitem +> <para +> longs are plain long's (expected to be 32 bit). </para +> </listitem +> <listitem +> <para +> Sequences use the C++ <acronym +>STL</acronym +> <classname +>vector</classname +> class. </para +> </listitem +> <listitem +> <para +> Structures are all derived from the &MCOP; class <classname +>Type</classname +>, and generated by the &MCOP; &IDL; compiler. When stored in sequences, they are not stored <quote +>plain</quote +> , but as pointers, as otherwise, too much copying would occur. </para +> </listitem +> </itemizedlist> +</sect2> + +<sect2 id="implementing-objects"> +<title +>Implementing &MCOP; Objects</title> + +<para +> After having them passed through the &IDL; compiler, you need to derive from the <classname +>_skel</classname +> class. For instance, consider you have defined your interface like this: </para> + +<programlisting> +// MCOP idl: hello.idl +interface Hello { + void hello(string s); + string concat(string s1, string s2); + long sum2(long a, long b); +}; +</programlisting> + +<para +> You pass that through the &IDL; compiler by calling <userinput +><command +>mcopidl</command +> <parameter +>hello.idl</parameter +></userinput +>, which will in turn generate <filename +>hello.cc</filename +> and <filename +>hello.h</filename +>. To implement it, you need to define a C++-class that inherits the skeleton: </para> + +<programlisting> +// C++ header file - include hello.h somewhere +class Hello_impl : virtual public Hello_skel { +public: + void hello(const string& s); + string concat(const string& s1, const string& s2); + long sum2(long a, long b); +}; +</programlisting> + +<para +> Finally, you need to implement the methods as normal C++ </para> + +<programlisting> +// C++ implementation file + +// as you see string's are passed as const string references +void Hello_impl::hello(const string& s) +{ + printf("Hello '%s'!\n",s.c_str()); +} + +// when they are a returncode they are passed as "normal" strings +string Hello_impl::concat(const string& s1, const string& s2) +{ + return s1+s2; +} + +long Hello_impl::sum2(long a, long b) +{ + return a+b; +} +</programlisting> + +<para +> Once you do that, you have an object which can communicate using &MCOP;. Just create one (using the normal C++ facilities to create an object): </para> + +<programlisting> + Hello_impl server; +</programlisting> + +<para +> And as soon as you give somebody the reference </para> + +<programlisting> + string reference = server._toString(); + printf("%s\n",reference.c_str()); +</programlisting> + +<para +> and go to the &MCOP; idle loop </para> + +<programlisting> +Dispatcher::the()->run(); +</programlisting> + +<para +> People can access the thing using </para> + +<programlisting> +// this code can run anywhere - not necessarily in the same process +// (it may also run on a different computer/architecture) + + Hello *h = Hello::_fromString([the object reference printed above]); +</programlisting> + +<para +> and invoke methods: </para> + +<programlisting> + if(h) + h->hello("test"); + else + printf("Access failed?\n"); +</programlisting> + +</sect2> +</sect1> + +<sect1 id="mcop-security"> +<title +>&MCOP; Security Considerations</title> + +<para +> Since &MCOP; servers will listen on a <acronym +>TCP</acronym +> port, potentially everybody (if you are on the Internet) may try to connect &MCOP; services. Thus, it is important to authenticate clients. &MCOP; uses the md5-auth protocol. </para> + +<para +> The md5-auth protocol does the following to ensure that only selected (trusted) clients may connect to a server: </para> + +<itemizedlist +> <listitem +> <para +> It assumes you can give every client a secret cookie. </para +> </listitem +> <listitem +> <para +> Every time a client connects, it verifies that this client knows that secret cookie, without actually transferring it (not even in a form that somebody listening to the network traffic could find it out). </para +> </listitem +> </itemizedlist> + +<para +> To give each client the secret cookie, &MCOP; will (normally) put it in the <filename class="directory" +>mcop</filename +> directory (under <filename class="directory" +>/tmp/mcop-<envar +>USER</envar +>/secret-cookie</filename +>). Of course, you can copy it to other computers. However, if you do so, use a secure transfer mechanism, such as <command +>scp</command +> (from <application +>ssh</application +>). </para> + +<para +> The authentication of clients uses the following steps: </para> + +<procedure +> <step +> <para +> [SERVER] generate a new (random) cookie R </para +> </step +> <step +> <para +> [SERVER] send it to the client </para +> </step +> <step +> <para +> [CLIENT] read the "secret cookie" S from a file </para +> </step +> <step +> <para +> [CLIENT] mangle the cookies R and S to a mangled cookie M using the MD5 algorithm </para +> </step +> <step +> <para +> [CLIENT] send M to the server </para +> </step +> <step +> <para +> [SERVER] verify that mangling R and S gives just the same thing as the cookie M received from the client. If yes, authentication is successful. </para +> </step +> </procedure> + +<para +> This algorithm should be secure, given that </para> + +<orderedlist +> <listitem +> <para +> The secret cookies and random cookies are <quote +>random enough</quote +> and </para +> </listitem +> <listitem +> <para +> The MD5 hashing algorithm doesn't allow to find out the <quote +>original text</quote +>, that is the secret cookie S and the random cookie R (which is known, anyway), from the mangled cookie M. </para +> </listitem +> </orderedlist> + +<para +> The &MCOP; protocol will start every new connection with an authentication process. Basically, it looks like this: </para> + +<procedure +> <step +> <para +> Server sends a ServerHello message, which describes the known authentication protocols. </para +> </step +> <step +> <para +> Client sends a ClientHello message, which includes authentication info. </para +> </step +> <step +> <para +> Server sends an AuthAccept message. </para +> </step +> </procedure> + +<para +> To see that the security actually works, we should look at how messages are processed on unauthenticated connections: </para> + +<itemizedlist +> <listitem +> <para +> Before the authentication succeeds, the server will not receive other messages from the connection. Instead, if the server for instance expects a <quote +>ClientHello</quote +> message, and gets an mcopInvocation message, it will drop the connection. </para +> </listitem +> <listitem +> <para +> If the client doesn't send a valid &MCOP; message at all (no &MCOP; magic in the message header) in the authentication phase, but something else, the connection is dropped. </para +> </listitem +> <listitem +> <para +> If the client tries to send a very very large message (> 4096 bytes in the authentication phase, the message size is truncated to 0 bytes, which will cause that it isn't accepted for authentication) This is to prevent unauthenticated clients from sending &zb; 100 megabytes of message, which would be received and could cause the server to run out of memory. </para +> </listitem +> <listitem +> <para +> If the client sends a corrupt ClientHello message (one, for which demarshalling fails), the connection is dropped. </para +> </listitem +> <listitem +> <para +> If the client send nothing at all, then a timeout should occur (to be implemented). </para +> </listitem +> </itemizedlist> + +</sect1> + +<sect1 id="mcop-protocol"> +<title +>&MCOP; Protocol Specification</title> + +<sect2 id="mcop-protocol-intro"> +<title +>Einleitung</title> + +<para +> It has conceptual similarities to <acronym +>CORBA</acronym +>, but it is intended to extend it in all ways that are required for real time multimedia operations. </para> + +<para +> It provides a multimedia object model, which can be used for both: communication between components in one adress space (one process), and between components that are in different threads, processes or on different hosts. </para> + +<para +> All in all, it will be designed for extremely high performance (so everything shall be optimized to be blazingly fast), suitable for very communicative multimedia applications. For instance streaming videos around is one of the applications of &MCOP;, where most <acronym +>CORBA</acronym +> implementations would go down to their knees. </para> + +<para +> The interface definitions can handle the following natively: </para> + +<itemizedlist +> <listitem +> <para +> Continous streams of data (such as audio data). </para +> </listitem +> <listitem +> <para +> Event streams of data (such as &MIDI; events). </para +> </listitem +> <listitem +> <para +> Real reference counting. </para +> </listitem +> </itemizedlist> + +<para +> and the most important <acronym +>CORBA</acronym +> gimmicks, like </para> + +<itemizedlist +> <listitem +> <para +> Synchronous method invocations. </para +> </listitem +> <listitem +> <para +> Asynchronous method invocations. </para +> </listitem +> <listitem +> <para +> Constructing user defined data types. </para +> </listitem +> <listitem +> <para +> Multiple inheritance. </para +> </listitem +> <listitem +> <para +> Passing object references. </para +> </listitem +> </itemizedlist> + +</sect2> + +<sect2 id="mcop-protocol-marshalling"> +<title +>The &MCOP; Message Marshalling</title> + +<para +> Design goals/ideas: </para> + +<itemizedlist +> <listitem +> <para +> Marshalling should be easy to implement. </para +> </listitem +> <listitem +> <para +> Demarshalling requires the receiver to know what type he wants to demarshall. </para +> </listitem +> <listitem +> <para +> The receiver is expected to use every information - so skipping is only in the protocol to a degree that: </para +> <itemizedlist +> <listitem +> <para +> If you know you are going to receive a block of bytes, you don't need to look at each byte for an end marker. </para +> </listitem +> <listitem +> <para +> If you know you are going to receive a string, you don't need to read it until the zero byte to find out it's length while demarshalling, however, </para +> </listitem +> <listitem +> <para +> If you know you are going to receive a sequence of strings, you need to look at the length of each of them to find the end of the sequence, as strings have variable length. But if you use the strings for something useful, you'll need to do that anyway, so this is no loss. </para +> </listitem +> </itemizedlist +> </listitem +> <listitem +> <para +> As little overhead as possible. </para +> </listitem +> </itemizedlist> + +<!-- TODO: Make this a table --> + +<para +> Marshalling of the different types is show in the table below: </para> + +<informaltable> +<tgroup cols="3"> +<thead +> <row +> <entry +>Type</entry +> <entry +>Marshalling Process</entry +> <entry +>Result</entry +> </row +> </thead> + +<tbody +> <row +> <entry +><type +>void</type +></entry +> <entry +><type +>void</type +> types are marshalled by omitting them, so nothing is written to the stream for them.</entry +> <entry +></entry +> </row +> <row +> <entry +><type +>long</type +></entry +> <entry +>is marshalled as four bytes, the most significant byte first, so the number 10001025 (which is 0x989a81) would be marshalled as:</entry +> <entry +><literal +>0x00 0x98 0x9a 0x81</literal +></entry +> </row +> <row +> <entry +><type +>enums</type +></entry +> <entry +><para +>are marshalled like <type +>long</type +>s</para +></entry +> <entry +></entry +> </row +> <row +> <entry +><type +>byte</type +></entry +> <entry +><para +>is marshalled as a single byte, so the byte 0x42 would be marshalled as:</para +></entry +> <entry +><literal +>0x42</literal +></entry +> </row +> <row +> <entry +><type +>string</type +></entry +> <entry +><para +>is marshalled as a <type +>long</type +>, containing the length of the following string, and then the sequence of characters strings must end with one zero byte (which is included in the length counting).</para +> <important +> <para +>include the trailing 0 byte in length counting!</para +> </important +> <para +><quote +>hello</quote +> would be marshalled as:</para +></entry +> <entry +><literal +>0x00 0x00 0x00 0x06 0x68 0x65 0x6c 0x6c 0x6f 0x00</literal +></entry +> </row +> <row +> <entry +><type +>boolean</type +></entry +> <entry +><para +>is marshalled as a byte, containing 0 if <returnvalue +>false</returnvalue +> or 1 if <returnvalue +>true</returnvalue +>, so the boolean value <returnvalue +>true</returnvalue +> is marshalled as:</para +></entry +> <entry +><literal +>0x01</literal +></entry +> </row +> <row +> <entry +><type +>float</type +></entry +> <entry +><para +>is marshalled after the four byte IEEE754 representation - detailed docs how IEEE works are here: <ulink url="http://twister.ou.edu/workshop.docs/common-tools/numerical_comp_guide/ncg_math.doc.html" +>http://twister.ou.edu/workshop.docs/common-tools/numerical_comp_guide/ncg_math.doc.html</ulink +> and here: <ulink url="http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html" +>http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html</ulink +>. So, the value 2.15 would be marshalled as:</para +></entry +> <entry +><literal +>0x9a 0x99 0x09 0x40</literal +></entry +> </row +> <row +> <entry +><type +>struct</type +></entry +> <entry +><para +>A structure is marshalled by marshalling it's contents. There are no additional prefixes or suffixes required, so the structure </para +> <programlisting> +struct test { + string name; // which is "hello" + long value; // which is 10001025 (0x989a81) +}; +</programlisting +> <para +>would be marshalled as</para +></entry +> <entry +> <literallayout> +0x00 0x00 0x00 0x06 0x68 0x65 0x6c 0x6c +0x6f 0x00 0x00 0x98 0x9a 0x81 +</literallayout +></entry +> </row +> <row +> <entry +><type +>sequence</type +></entry +> <entry +><para +>a sequence is marshalled by listing the number of elements that follow, and then marshalling the elements one by one.</para +> <para +>So a sequence of 3 longs a, with a[0] = 0x12345678, a[1] = 0x01 and a[2] = 0x42 would be marshalled as:</para +></entry +> <entry +> <literallayout> +0x00 0x00 0x00 0x03 0x12 0x34 0x56 0x78 +0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x42 +</literallayout +> </entry +> </row +> </tbody> +</tgroup> +</informaltable> + +<para +> If you need to refer to a type, all primitive types are referred by the names given above. Structures and enums get own names (like Header). Sequences are referred as *<replaceable +>normal type</replaceable +>, so that a sequence of longs is <quote +>*long</quote +> and a sequence of Header struct's is <quote +>*Header</quote +>. </para> + +</sect2> + +<sect2 id="mcop-protocol-messages"> +<title +>Messages</title> + +<para +> The &MCOP; message header format is defined as defined by this structure: </para> + +<programlisting> +struct Header { + long magic; // the value 0x4d434f50, which is marshalled as MCOP + long messageLength; + long messageType; +}; +</programlisting> + +<para +> The possible messageTypes are currently </para> + +<programlisting> + mcopServerHello = 1 + mcopClientHello = 2 + mcopAuthAccept = 3 + mcopInvocation = 4 + mcopReturn = 5 + mcopOnewayInvocation = 6 +</programlisting> + +<para +> A few notes about the &MCOP; messaging: </para> + + +<itemizedlist +> <listitem +> <para +> Every message starts with a Header. </para +> </listitem +> <listitem +> <para +> Some messages types should be dropped by the server, as long as the authentication is not complete. </para +> </listitem +> <listitem +> <para +> After receiving the header, the protocol (connection) handling can receive the message completely, without looking at the contents. </para +> </listitem +> </itemizedlist> + +<para +> The messageLength in the header is of course in some cases redundant, which means that this approach is not minimal regarding the number of bytes. </para> + +<para +> However, it leads to an easy (and fast) implementation of non-blocking messaging processing. With the help of the header, the messages can be received by protocol handling classes in the background (non-blocking), if there are many connections to the server, all of them can be served parallel. You don't need to look at the message content, to receive the message (and to determine when you are done), just at the header, so the code for that is pretty easy. </para> + +<para +> Once a message is there, it can be demarshalled and processed in one single pass, without caring about cases where not all data may have been received (because the messageLength guarantees that everything is there). </para> + +</sect2> + +<sect2 id="mcop-protocol-invocations"> +<title +>Invocations</title> + +<para +> To call a remote method, you need to send the following structure in the body of an &MCOP; message with the messageType = 1 (mcopInvocation): </para> + +<programlisting> +struct Invocation { + long objectID; + long methodID; + long requestID; +}; +</programlisting> + +<para +> after that, you send the parameters as structure, &zb; if you invoke the method string concat(string s1, string s2), you send a structure like </para> + +<programlisting> +struct InvocationBody { + string s1; + string s2; +}; +</programlisting> + + +<para +> if the method was declared to be oneway - that means asynchronous without return code - then that was it. Otherwise, you'll receive as answer the message with messageType = 2 (mcopReturn) </para> + +<programlisting> +struct ReturnCode { + long requestID; + <resulttype> result; +}; +</programlisting> + + +<para +> where <resulttype> is the type of the result. As void types are omitted in marshalling, you can also only write the requestID if you return from a void method. </para> + +<para +> So our string concat(string s1, string s2) would lead to a returncode like </para> + +<programlisting> +struct ReturnCode { + long requestID; + string result; +}; +</programlisting> + +</sect2> + +<sect2 id="mcop-protocol-inspecting"> +<title +>Inspecting Interfaces</title> + +<para +> To do invocations, you need to know the methods an object supports. To do so, the methodID 0, 1, 2 and 3 are hardwired to certain functionalities. That is </para> + +<programlisting> +long _lookupMethod(MethodDef methodDef); // methodID always 0 +string _interfaceName(); // methodID always 1 +InterfaceDef _queryInterface(string name); // methodID always 2 +TypeDef _queryType(string name); // methodID always 3 +</programlisting> + +<para +> to read that, you of course need also </para> + +<programlisting> +struct MethodDef { + string methodName; + string type; + long flags; // set to 0 for now (will be required for streaming) + sequence<ParamDef> signature; +}; + +struct ParamDef { + string name; + long typeCode; +}; +</programlisting> + +<para +> the parameters field contains type components which specify the types of the parameters. The type of the returncode is specified in the MethodDef's type field. </para> + +<para +> Strictly speaking, only the methods <methodname +>_lookupMethod()</methodname +> and <methodname +>_interfaceName()</methodname +> differ from object to object, while the <methodname +>_queryInterface()</methodname +> and <methodname +>_queryType()</methodname +> are always the same. </para> + +<para +> What are those methodIDs? If you do an &MCOP; invocation, you are expected to pass a number for the method you are calling. The reason for that is, that numbers can be processed much faster than strings when executing an &MCOP; request. </para> + +<para +> So how do you get those numbers? If you know the signature of the method, that is a MethodDef that describes the method, (which contains name, type, parameter names, parameter types and such), you can pass that to _lookupMethod of the object where you wish to call a method. As _lookupMethod is hardwired to methodID 0, you should encounter no problems doing so. </para> + +<para +> On the other hand, if you don't know the method signature, you can find which methods are supported by using _interfaceName, _queryInterface and _queryType. </para> +</sect2> + +<sect2 id="mcop-protocol-typedefs"> +<title +>Type Definitions</title> + +<para +> User defined datatypes are described using the <structname +>TypeDef</structname +> structure: </para> + +<programlisting> +struct TypeComponent { + string type; + string name; +}; + +struct TypeDef { + string name; + + sequence<TypeComponent> contents; +}; +</programlisting> + +</sect2> +</sect1> + +<sect1 id="why-not-dcop"> +<title +>Why &arts; Doesn't Use &DCOP;</title> + +<para +> Since &kde; dropped <acronym +>CORBA</acronym +> completely, and is using &DCOP; everywhere instead, naturally the question arises why &arts; isn't doing so. After all, &DCOP; support is in <classname +>KApplication</classname +>, is well-maintained, supposed to integrate greatly with libICE, and whatever else. </para> + +<para +> Since there will be (potentially) a lot of people asking whether having &MCOP; besides &DCOP; is really necessary, here is the answer. Please don't get me wrong, I am not trying to say <quote +>&DCOP; is bad</quote +>. I am just trying to say <quote +>&DCOP; isn't the right solution for &arts;</quote +> (while it is a nice solution for other things). </para> + +<para +> First, you need to understand what exactly &DCOP; was written for. Created in two days during the &kde;-TWO meeting, it was intended to be as simple as possible, a really <quote +>lightweight</quote +> communication protocol. Especially the implementation left away everything that could involve complexity, for instance a full blown concept how data types shall be marshalled. </para> + +<para +> Even although &DCOP; doesn't care about certain things (like: how do I send a string in a network-transparent manner?) - this needs to be done. So, everything that &DCOP; doesn't do, is left to &Qt; in the &kde; apps that use &DCOP; today. This is mostly type management (using the &Qt; serialization operator). </para> + +<para +> So &DCOP; is a minimal protocol which perfectly enables &kde; applications to send simple messages like <quote +>open a window pointing to http://www.kde.org</quote +> or <quote +>your configuration data has changed</quote +>. However, inside &arts; the focus lies on other things. </para> + +<para +> The idea is, that little plugins in &arts; will talk involving such data structures as <quote +>midi events</quote +> and <quote +>songposition pointers</quote +> and <quote +>flow graphs</quote +>. </para> + +<para +> These are complex data types, which must be sent between different objects, and be passed as streams, or parameters. &MCOP; supplies a type concept, to define complex data types out of simpler ones (similar to structs or arrays in C++). &DCOP; doesn't care about types at all, so this problem would be left to the programmer - like: writing C++ classes for the types, and make sure they can serialize properly (for instance: support the &Qt; streaming operator). </para> + +<para +> But that way, they would be inaccessible to everything but direct C++ coding. Specifically, you could not design a scripting language, that would know all types plugins may ever expose, as they are not self describing. </para> + +<para +> Much the same argument is valid for interfaces as well. &DCOP; objects don't expose their relationships, inheritance hierarchies, etc. - if you were to write an object browser which shows you <quote +>what attributes has this object got</quote +>, you'd fail. </para> + + +<para +> While Matthias told me that you have a special function <quote +>functions</quote +> on each object that tells you about the methods that an object supports, this leaves out things like attributes (properties), streams and inheritance relations. </para> + +<para +> This seriously breaks applications like &arts-builder;. But remember: &DCOP; was not so much intended to be an object model (as &Qt; already has one with <application +>moc</application +> and similar), nor to be something like <acronym +>CORBA</acronym +>, but to supply inter-application communication. </para> + +<para +> Why &MCOP; even exists is: it should work fine with streams between objects. &arts; makes heavily use of small plugins, which interconnect themselves with streams. The <acronym +>CORBA</acronym +> version of &arts; had to introduce a very annoying split between <quote +>the SynthModule objects</quote +>, which were the internal work modules that did do the streaming, and <quote +>the <acronym +>CORBA</acronym +> interface</quote +>, which was something external. </para> + +<para +> Much code cared about making interaction between <quote +>the SynthModule objects</quote +> and <quote +>the <acronym +>CORBA</acronym +> interface</quote +> look natural, but it didn't, because <acronym +>CORBA</acronym +> knew nothing at all about streams. &MCOP; does. Look at the code (something like <filename +>simplesoundserver_impl.cc</filename +>). Way better! Streams can be declared in the interface of modules, and implemented in a natural looking way. </para> + +<para +> One can't deny it. One of the reasons why I wrote &MCOP; was speed. Here are some arguments why &MCOP; will definitely be faster than &DCOP; (even without giving figures). </para> + + +<para +> An invocation in &MCOP; will have a six-<quote +>long</quote +>-header. That is: </para> + +<itemizedlist +> <listitem +><para +>magic <quote +>MCOP</quote +></para +></listitem +> <listitem +><para +>message type (invocation)</para +></listitem +> <listitem +><para +>size of the request in bytes</para +></listitem +> <listitem +><para +>request ID</para +></listitem +> <listitem +><para +>target object ID</para +></listitem +> <listitem +><para +>target method ID</para +></listitem +> </itemizedlist> + +<para +> After that, the parameters follow. Note that the demarshalling of this is extremely fast. You can use table lookups to find the object and the method demarshalling function, which means that complexity is O(1) [ it will take the same amount of time, no matter how many objects are alive, or how many functions are there ]. </para> + +<para +> Comparing this to &DCOP;, you'll see, that there are at least </para> + +<itemizedlist +> <listitem +><para +>a string for the target object - something like <quote +>myCalculator</quote +></para +></listitem +> <listitem +><para +>a string like <quote +>addNumber(int,int)</quote +> to specify the method</para +></listitem +> <listitem +><para +>several more protocol info added by libICE, and other DCOP specifics I don't know</para +></listitem +> </itemizedlist> + +<para +> These are much more painful to demarshall, as you'll need to parse the string, search for the function, &etc;. </para> + +<para +> In &DCOP;, all requests are running through a server (<application +>DCOPServer</application +>). That means, the process of a synchronous invocation looks like this: </para> + +<itemizedlist +> <listitem +> <para +> Client process sends invocation. </para +> </listitem +> <listitem +> <para +> <application +>DCOPserver</application +> (man-in-the-middle) receives invocation and looks where it needs to go, and sends it to the <quote +>real</quote +> server. </para +> </listitem +> <listitem +> <para +> Server process receives invocation, performs request and sends result. </para +> </listitem +> <listitem +> <para +> <application +>DCOPserver</application +> (man-in-the-middle) receives result and ... sends it to the client. </para +> </listitem +> <listitem +> <para +> Client decodes reply. </para +> </listitem +> </itemizedlist> + +<para +> In &MCOP;, the same invocation looks like this: </para> + +<itemizedlist +> <listitem +> <para +> Client process sends invocation. </para +> </listitem +> <listitem +> <para +> Server process receives invocation, performs request and sends result. </para +> </listitem +> <listitem +> <para +> Client decodes reply. </para +> </listitem +> </itemizedlist> + +<para +> Say both were implemented correctly, &MCOP;s peer-to-peer strategy should be faster by a factor of two, than &DCOP;s man-in-the-middle strategy. Note however that there were of course reasons to choose the &DCOP; strategy, which is namely: if you have 20 applications running, and each app is talking to each app, you need 20 connections in &DCOP;, and 200 with &MCOP;. However in the multimedia case, this is not supposed to be the usual setting. </para> + +<para +> I tried to compare &MCOP; and &DCOP;, doing an invocation like adding two numbers. I modified testdcop to achieve this. However, the test may not have been precise on the &DCOP; side. I invoked the method in the same process that did the call for &DCOP;, and I didn't know how to get rid of one debugging message, so I used output redirection. </para> + +<para +> The test only used one object and one function, expect &DCOP;s results to decrease with more objects and functions, while &MCOP;s results should stay the same. Also, the <application +>dcopserver</application +> process wasn't connected to other applications, it might be that if many applications are connected, the routing performance decreases. </para> + +<para +> The result I got was that while &DCOP; got slightly more than 2000 invocations per second, &MCOP; got slightly more than 8000 invocations per second. That makes a factor of 4. I know that &MCOP; isn't tuned to the maximum possible, yet. (Comparision: <acronym +>CORBA</acronym +>, as implemented with mico, does something between 1000 and 1500 invocations per second). </para> + +<para +> If you want <quote +>harder</quote +> data, consider writing some small benchmark app for &DCOP; and send it to me. </para> + +<para +> <acronym +>CORBA</acronym +> had the nice feature that you could use objects you implemented once, as <quote +>seperate server process</quote +>, or as <quote +>library</quote +>. You could use the same code to do so, and <acronym +>CORBA</acronym +> would transparently descide what to do. With &DCOP;, that is not really intended, and as far as I know not really possible. </para> + +<para +> &MCOP; on the other hand should support that from the beginning. So you can run an effect inside &artsd;. But if you are a wave editor, you can choose to run the same effect inside your process space as well. </para> + +<para +> While &DCOP; is mostly a way to communicate between apps, &MCOP; is also a way to communicate inside apps. Especially for multimedia streaming, this is important (as you can run multiple &MCOP; objects parallely, to solve a multimedia task in your application). </para> + +<para +> Although &MCOP; does not currently do so, the possibilities are open to implement quality of service features. Something like <quote +>that &MIDI; event is really really important, compared to this invocation</quote +>. Or something like <quote +>needs to be there in time</quote +>. </para> + +<para +> On the other hand, stream transfer can be integrated in the &MCOP; protocol nicely, and combined with <acronym +>QoS</acronym +> stuff. Given that the protocol may be changed, &MCOP; stream transfer should not really get slower than conventional <acronym +>TCP</acronym +> streaming, but: it will be easier and more consistent to use. </para> + +<para +> There is no need to base a middleware for multimedia on &Qt;. Deciding so, and using all that nice &Qt;-streaming and stuff, will easily lead to the middleware becoming a &Qt;-only (or rather &kde;-only) thing. I mean: as soon as I'll see the GNOMEs using &DCOP;, too, or something like that, I am certainly proven wrong. </para> + +<para +> While I do know that &DCOP; basically doesn't know about the data types it sends, so that you could use &DCOP; without using &Qt;, look at how it is used in daily &kde; usage: people send types like <classname +>QString</classname +>, <classname +>QRect</classname +>, <classname +>QPixmap</classname +>, <classname +>QCString</classname +>, ..., around. These use &Qt;-serialization. So if somebody choose to support &DCOP; in a GNOME program, he would either have to claim to use <classname +>QString</classname +>,... types (although he doesn't do so), and emulate the way &Qt; does the streaming, or he would send other string, pixmap and rect types around, and thus not be interoperable. </para> + +<para +> Well, whatever. &arts; was always intended to work with or without &kde;, with or without &Qt;, with or without X11, and maybe even with or without &Linux; (and I have even no problems with people who port it to a popular non-free operating systems). </para> + +<para +> It is my position that non-&GUI;-components should be written non-&GUI;-dependant, to make sharing those among wider amounts of developers (and users) possible. </para> + +<para +> I see that using two <acronym +>IPC</acronym +> protocols may cause inconveniences. Even more, if they are both non-standard. However, for the reasons given above, switching to &DCOP; is no option. If there is significant interest to find a way to unite the two, okay, we can try. We could even try to make &MCOP; speak <acronym +>IIOP</acronym +>, then we'd have a <acronym +>CORBA</acronym +> <acronym +>ORB</acronym +> ;). </para> + +<para +> I talked with Matthias Ettrich a bit about the future of the two protocols, and we found lots of ways how things could go on. For instance, &MCOP; could handle the message communication in &DCOP;, thus bringing the protocols a bit closer together. </para> + +<para +> So some possible solutions would be: </para> + +<itemizedlist +> <listitem +> <para +> Write an &MCOP; - &DCOP; gateway (which should be possible, and would make interoperation possible) - note: there is an experimental prototype, if you like to work on that. </para +> </listitem +> <listitem +> <para +> Integrate everything &DCOP; users expect into &MCOP;, and try to only do &MCOP; - one could add an <quote +>man-in-the-middle-option</quote +> to &MCOP;, too ;) </para +> </listitem +> <listitem +> <para +> Base &DCOP; on &MCOP; instead of libICE, and slowly start integrating things closer together. </para +> </listitem +> </itemizedlist> + +<para +> However, it may not be the worst possibility to use each protocol for everything it was intended for (there are some big differences in the design goals), and don't try to merge them into one. </para> + +</sect1> +</chapter> + + + diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/midi.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/midi.docbook new file mode 100644 index 00000000000..dd750a8a52c --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/midi.docbook @@ -0,0 +1,506 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="midi"> +<title +>&MIDI;</title> + +<sect1 id="midi-overview"> +<title +>Überblick</title> + +<!-- what-to-say-here: aRts has three roles + * moving midi events around between applications + * abstracting the hardware + * synthesizer --> + +<para +>Die &MIDI;-Unterstützung in &arts; hat verschiedene Aufgaben. Erstens ermöglicht sie die <emphasis +>Kommunikation</emphasis +> von verschiedenen Programmteilen, die &MIDI;-Ereignisse erzeugen oder verarbeiten. Wenn Sie z.B. über einen Sequenzer und einen Sampler verfügen, die beide &arts; unterstützen, kann &arts; &MIDI;-Ereignisse vom Sequenzer zum Sampler senden. </para> + +<para +>Auf der anderen Seite kann &arts; für ein Programm die <emphasis +>Interaktion mit Geräten</emphasis +> übernehmen. Wenn ein Programm (z.B. ein Sampler) &arts; unterstützt, kann es genau so gut &MIDI;-Ereignisse von einem externen &MIDI;-Keyboard empfangen. </para> + +<para +>Schließlich ist &arts; ein hervorragender <emphasis +>modularer Synthesizer</emphasis +>. Er ist genau dafür entworfen worden. Sie können mit artsbuilder aus den kleinen Modulen Instrumente zusammenstellen und diese Instrumente dann für Kompositionen oder zum Abspielen von Musik verwenden. Synthese heißt nicht notwendigerweise reine Synthese, es gibt Module, die Sie zum Abspielen von Samples verwenden können. Also kann &arts; ein Sampler, ein Synthesizer und mehr sein; &arts; ist vollständig modular, also leicht zum Erweitern und Experimentieren geeignet, mächtig und flexibel. </para> +</sect1> + +<sect1 id="midi-manager"> +<title +>Der &MIDI;-Manager</title> +<!-- what-to-say-here: + * how to use artscontrol - view midimanager + * what does autorestore do? (not yet implemented - so not yet documented) --> + +<para +>Die zentrale Komponente für Midi-Ereignisse innerhalb von &arts; ist der Midi-Manager. Er kontrolliert, welche Anwendungen verbunden sind und wie Midi-Ereignisse zwischen ihnen übertragen und verarbeitet werden sollen. Der Midi-Manager wird durch artscontrol gesteuert. Wählen Sie dazu <menuchoice +><guilabel +>Ansicht</guilabel +><guilabel +>Midi-Manager</guilabel +> </menuchoice +> im Menü. </para> + +<para +>Auf der linken Seite sehen Sieh <guilabel +>Midi-Eingänge</guilabel +>. Hier werden alle Geräte aufgelistet, die &MIDI;-Ereignisse produzieren. Das können externe &MIDI;-Kanäle sein, die mit einem externen Keyboard verbunden sind, ein Sequenzer, der ein Musikstück abspielt, oder eine andere &MIDI;-Quelle. Auf der rechten Seite sehen Sie <guilabel +>&MIDI;-Ausgänge</guilabel +>. Alle Geräte oder Programme, die &MIDI;-Ereignisse verarbeiten, sind hier aufgelistet. Das können simulierte Sampler (als Programme) oder externe &MIDI;-Kanäle, an denen ein Hardware-Sampler angeschlossen ist, sein. Neue Programme, wie z.B. Sequenzer, registrieren sich bei dem Midi-Manager, daher kann sich der Listeninhalt von Zeit zu Zeit ändern. </para> + +<para +>Sie können Ein- und Ausgänge verbinden, indem Sie den gewünschten Eingang auf der linken und den Ausgang auf der rechten Seite markieren und auf <guilabel +>Verbinden</guilabel +> klicken. Eine Trennung erreichen Sie mit dem Knopf <guilabel +>Trennen</guilabel +>. Die bestehenden Verbindungen werden durch günne Linien zwischen den Listen angezeigt. Sie können einen Midi-Eingang mit mehreren Midi-Ausgängen verbinden und umgekehrt. </para> + +<para +>Programme (wie der Sequenzer Brahms) fügen sich beim Start selbstständig zur entsprechenden Liste hinzu und entfernen sich beim Beenden selbstständig. Sie können aber auch von Hand Einträge hinzufügen, indem Sie im Menü <guilabel +>Hinzufügen</guilabel +> wählen. </para> + +<variablelist> +<varlistentry> +<term +><guimenuitem +>System-Midi-Kanal (OSS)</guimenuitem +></term> +<listitem> +<para +>Dadurch wird ein neues &arts;-Objekt erzeugt, das einen externen Midi-Kanal repräsentiert. </para> + +<para +>Da externe Midi-Kanäle sowohl senden als auch empfangen können, wird zu beiden Listen ein Eintrag hinzugefügt. Unter &Linux; benötigen Sie entweder einen <acronym +>OSS</acronym +>- (<acronym +>OSS/Free</acronym +> liegt Ihrem &Linux;-Kernel bei) oder einen <acronym +>ALSA</acronym +>-Treiber für Ihre Soundkarte installiert haben. Sie werden nach dem Gerätenamen gefragt. Er lautet normalerweise <filename class="devicefile" +>/dev/midi</filename +> oder <filename class="devicefile" +>/dev/midi00</filename +>. </para> + +<para +> Wenn Sie allerdings mehr als ein &MIDI;-Gerät oder einen &MIDI;-Loopback-Treiber installiert haben, ist die Auswahl größer. Informationen über die verfügbaren Midi-Kanäle finden Sie im &kcontrolcenter; unter <menuchoice +><guilabel +>Information</guilabel +> <guilabel +>Klänge</guilabel +></menuchoice +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>aRts Synthese Midi-Ausgang</guimenuitem +></term> +<listitem> +<para +>Fügt einen neuen &MIDI;-Ausgang mit einem &arts;-Synthese-Instrument hinzu. Wenn Sie diesen Menüeintrag wählen, erscheint ein Dialog, der Ihnen die Wahl eines Instrumentes ermöglicht. Mit artsbuilder können Sie neue Instrumente erstellen. Alle <literal role="extension" +>.arts</literal +>-Dateien, die mit <filename +>instrument_</filename +> beginnen, werden hier aufgelistet. </para> +</listitem> +</varlistentry> +</variablelist> + +</sect1> + +<sect1 id="brahms"> +<title +>Verwendung von &arts; & Brahms</title> + +<para +>Zuerst benötigen Sie eine &kde; 2.1-taugliche Version von &brahms;. Sie finden Sie im <literal +>kmusic</literal +> <acronym +>CVS</acronym +>-Modul. Weitere Informationen zu &brahms; finden Sie auf der <ulink url="http://www.arts-project.org/" +>aRts-Internetseite</ulink +> im Bereich Download. </para> + +<para +>Wenn man die Anwendung startet, wird zunächst der &MIDI;-Manager angezeigt. Wenn man Klänge synthetisieren will, fügt man ein &MIDI;-Synthesizerinstrument über <menuchoice +><guilabel +>Hinzufügen</guilabel +><guilabel +>aRts Synthese Midi-Ausgang</guilabel +> </menuchoice +> hinzu. </para> + +<para +>Man wählt ein Instrument (zum Beispiel <guilabel +>organ2</guilabel +>). Man verbindet das Instrument über den Knopf <guilabel +>Verbinden</guilabel +>. Danach kann man mit &brahms; komponieren und die Ausgabe wird durch &arts; synthetisiert. </para> + +<para +>Man sollte das &artscontrol;-Fenster geöffnet lassen und die Lautstärkeeinstellung kontrollieren (die Qualität wird schlecht, wenn die Lautstärkeanzeige an die obere Grenze stösst). Nun kann man einneues Demolied für &arts; erstellen und es, wenn es fertig ist, unter aRts-project.org veröffentlichen ;-). </para> + +<!-- TODO: how to do more than one instrument in Brahms (hm, not implemented + yet, not documented yet), how to use samples, mapping and so on. These + things need to be implemented, too. --> + +</sect1> + +<sect1 id="midisend"> +<title +>midisend</title> + +<para +><command +>midisend</command +> ist ein kleines Programm, das &MIDI;-Ereignisse von der Kommandozeile senden kann. Es registriert sich als &MIDI;-Eingang wie alle anderen Anwendungen. Um es zu verwenden, geben Sie <screen +><prompt +>%</prompt +> <userinput +><command +>midisend</command +> <option +>-f</option +> <parameter +><replaceable +>/dev/midi00</replaceable +></parameter +></userinput +> </screen +> ein. Damit wird etwa das gleiche erreicht, wie durch das Hinzufügen eines System-Midikanals in artscontrol (nicht ganz, da midisend nur &MIDI;-Ereignisse senden aber nicht empfangen kann). Der Unterschied ist, das midisend auf unterschiedlichen Computern gestartet werden kann (und damit Netzwerktransparenz ermöglicht). </para> + +<para +>Sie können <command +>midisend</command +> auch Daten von <filename class="devicefile" +>stdin</filename +> senden lassen. Mit dem folgenden Befehl können sie Daten von Anwendungen, die &arts; nicht unterstützen, an &arts; weiterleiten: <screen +><prompt +>%</prompt +> <userinput +><command +><replaceable +>applicationwhichproducesmidieventsonstdout</replaceable +></command +> | <command +>midisend</command +> <option +>-f</option +> <option +><replaceable +>-</replaceable +></option +></userinput +></screen> +<!-- TODO: document all options --> +</para> + +</sect1> + +<sect1 id="midi-creating-instruments"> +<title +>Instrumente erstellen</title> + +<para +>&arts; synthetisiert Midi-Klänge auf folgende Weise. Es gibt eine Struktur, die einige Eingabekanäle, aus denen Frequenz und Lautstärke (velocity) und ein Parameter gelesen wird. Der Parameter zeigt an, ob die Taste noch heruntergedrückt ist. Die Struktur soll nun diese eine Note mit dieser Lautstärke und Frequenz erzeugen. Außerdem soll die Struktur auf den Wert des Parameters gedrückt reagieren (dabei bedeutet gedrückt=1 der Benutzer drückt die Taste immer noch herunter und gedrückt=0 die Taste wurde losgelassen). </para> + +<para +>Eingehende &MIDI;-Ereignisse veranlassen &arts;, neue Strukturen für jede gedrückte Taste zu generieren, ihnen die entsprechenden Parameter mitzugeben und sie wieder zu entfernen, sobald sie nicht mehr benötigt werden. </para> + +<para +>Eine Struktur wird auf folgende Art erzeugt und verwendet: </para> + +<itemizedlist> +<listitem> +<para +>Zum Beginn ist es am einfachsten, ein <filename +>template_Instrument.arts</filename +> in &arts-builder; zu öffnen. </para> + +<para +>Wählen Sie dazu <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Beispiel öffnen ...</guimenuitem +></menuchoice +> im Menü und im Dateidialog wählen Sie template_Instrument. Damit haben Sie eine leere Struktur mit den erforderlichen Parametern erzeugt, die Sie nur noch "ausfüllen" müssen. </para> +</listitem> + +<listitem> +<para +>Für den Parameter pressed(gedrückt) benutzen Sie entweder Synth_ENVELOPE_ADSR oder, für eine Schlagzeug wav-Datei, spielen sie einfach ab und ignorieren den Parameter. </para> +</listitem> + +<listitem> +<para +>Die Struktur sollte am Ausgang <quote +>done</quote +> anzeigen, das Sie nicht mehr benötigt wird. Wenn doneauf 1 gesetzt wird, nimmt &arts; an, das er die Struktur löschen kann. Angenehmerweise stellt das ADSR-Hüllkurven-Modul einen Parameter bereit, der anzeigt, wenn das Modul fertig ist. Sie müssen diesen Ausgang lediglich mit dem done-Ausgang Ihrer Struktur verbinden. </para> +</listitem> + +<listitem> +<para +>Sie sollten die Struktur in die Form <filename +>instrument_*</filename +> wie z.B. <filename +>instrument_piano.arts</filename +> umbenennen - unter diesem Namen sollten Sie die Struktur unter <filename class="directory" +>$<envar +>HOME</envar +>/arts/structures</filename +> speichern (dort speichert artsbuilder normalerweise Strukturen). </para> +</listitem> + +<listitem> +<para +>Schließlich, nachdem die Struktur gespeichert ist, können Sie sie im &MIDI;-Manager von artscontrol verwenden.</para> +</listitem> + +<listitem> +<para +>Und Sie müssen natürlich die Struktur so einrichten, das Sie ihre Audiodaten an den linken und rechten Ausgangskanal sendet, so dass sie schließlich durch den Audio-Manager (ein Teil von &artscontrol;) hörbar werden (oder sie mit Effekten weiterverarbeiten). </para> +</listitem> +</itemizedlist> + +<para +>Um zu lernen, wie Sie selbst ein Instrument erstellen, können Sie ein bereits vorhandenes Instrument analysieren (wählen Sie im Menü <menuchoice +><guimenu +>Datei</guimenu +><guimenuitem +>Beispiel öffnen</guimenuitem +></menuchoice +>). </para> +</sect1> + +<sect1 id="mapped-instruments"> +<title +>gemappte Instrumente</title> + +<para +>Gemappte Instrumente sind Instrumente, die sich abhängig von der Tonhöhe (pitch), dem Programm, dem Kanal und der Lautstärke (velocity) unterschiedlich verhalten. Sie könnten z.B. einen Klavierklang von 5 Oktaven bilden, indem Sie ein Sample für jede Oktave verwenden (entsprechende Höhenverschiebungen (pitchshifting) vorausgesetzt). Dieser Klang wird besser klingen als ein Sample für alle Oktaven. </para> + +<para +>Sie können auch eine Schlagzeug-Map bilden, die jeder Taste ein bestimmtes Schlaginstrument zuordnet. </para> + +<para +>Es ist sehr nützlich, wenn Sie einige unterschiedliche Klänge in ein gemapptes Instrument für verschiedene Programme zusammenfügen. Auf diese Weise können Sie Ihren Sequenzer, externes Keyboard oder andere &MIDI;-Quelle verwenden, um zwischen den Klängen umzuschalten, ohne das Sie &arts; umändern müssen. </para> + +<para +>Ein gutes Beispiel dafür ist das Instrument <filename +>arts_all</filename +>. Es fügt alle Instrumente in einer Map zusammen. Auf diese Weise müssen Sie lediglich einmal in &artscontrol; dieses <quote +>instrument</quote +> registrieren und schon können Sie ein komplettes Musikstück in einem Sequenzer komponieren, ohne &arts; umzuschalten. Wenn Sie einen anderen Klang benötigen, wechseln Sie einfach im Sequenzer das Programm und &arts; erzeugt einen anderen Klang. </para> + +<para +>Solche Maps können Sie auf einfache Weise erstellen. Sie müssen lediglich eine Textdatei anlegen, die einige Regeln enthält: </para> + +<programlisting +>ON <replaceable +>[ Bedingungen ...]</replaceable +> DO structure=<replaceable +>irgendeine Struktur</replaceable +>.arts +</programlisting> + +<para +>Die Bedingungen können eine oder mehrere der folgenden sein: </para> + +<variablelist> + +<varlistentry> +<term +><option +>pitch (Tonhöhe)</option +></term> + +<listitem> +<para +>Beim pitch handelt es sich um die gespielte Tonhöhe. Diese Bedingung verwenden Sie, wenn Sie den Instrumentenklang abhängig von der Tonhöhe aufteilen wollen. Von den Anfangsbeispielen würde ein Piano, das verschiedene Klänge für verschiedene Oktaven verwendet, mit einer solchen Bedingung erstellt. Sie können eine bestimmte Tonhöhe angeben, wie z.B. pitch=<parameter +>62</parameter +> oder einen Bereich wie pitch=<parameter +>60</parameter +>-<parameter +>72</parameter +>. Die möglichen Tonhöhen liegen zwischen <parameter +>0</parameter +> und <parameter +>127</parameter +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>program (Programm)</option +></term> +<listitem> +<para +>Das Programm, das auf dem Midi-Kanal aktiv ist, auf dem die Note gesendet wird. Üblicherweise kann man bei einem Sequenzer das <quote +>Instrument</quote +> über die Programmeinstellung auswählen. Einzelne Programme oder Bereiche sind erlaubt, also <userinput +><option +>program</option +>=<parameter +>3</parameter +></userinput +> oder <userinput +><option +>program</option +>=<parameter +>3</parameter +>-<parameter +>6</parameter +> </userinput +>. Die möglichen Programmeinstellungen reichen von <parameter +>0</parameter +> bis <parameter +>127</parameter +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>channel (Kanal)</option +></term> +<listitem> +<para +>Der Kanal, auf dem die Note gesendet wird. Einzelne Kanäle oder Kanalbereiche sind möglich, z.B. <userinput +><option +>channel</option +>=<parameter +>0</parameter +></userinput +> oder <userinput +><option +>channel</option +>=<parameter +>0</parameter +>-<parameter +>8</parameter +> </userinput +>. Die möglichen Werte liegen zwischen <parameter +>0</parameter +> und <parameter +>15</parameter +>. </para> +</listitem> + +</varlistentry> +<varlistentry> +<term +><option +>velocity (Lautstärke)</option +></term> +<listitem> +<para +>Die Lautstärke, die die Note hat. Einzelne Lautstärken (wofür eigentlich) oder Bereiche sind möglich, also <userinput +><option +>velocity</option +>=<parameter +>127</parameter +></userinput +> oder <userinput +><option +>veclocity</option +>=<parameter +>64</parameter +>-<parameter +>127</parameter +> </userinput +>. Die möglichen Werte liegen zwischen <parameter +>0</parameter +> und <parameter +>127</parameter +>. </para> +</listitem> +</varlistentry> +</variablelist> + +<para +>Ein komplettes Beispiel für eine Map sieht folgendermaßen aus (das Beispiel stammt aus <filename +>instrument_arts_all.arts-map</filename +>): </para> + +<programlisting +>ON program=0 DO structure=instrument_tri.arts +ON program=1 DO structure=instrument_organ2.arts +ON program=2 DO structure=instrument_slide1.arts +ON program=3 DO structure=instrument_square.arts +ON program=4 DO structure=instrument_neworgan.arts +ON program=5 DO structure=instrument_nokind.arts +ON program=6 DO structure=instrument_full_square.arts +ON program=7 DO structure=instrument_simple_sin.arts +ON program=8 DO structure=instrument_simple_square.arts +ON program=9 DO structure=instrument_simple_tri.arts +ON program=10 DO structure=instrument_slide.arts +ON program=11 pitch=60 DO structure=instrument_deepdrum.arts +ON program=11 pitch=61 DO structure=instrument_chirpdrum.arts +</programlisting> + +<para +>Wie Sie sehen, wird die Struktur abhängig vom Programm ausgewählt, beispielsweise sehen Sie als Programm 11 eine <quote +>Schlagzeug-Map</quote +> (mit zwei Einträgen), die eine <quote +>tiefe Trommel</quote +> auf C-5 (pitch=60) und eine <quote +>Snare-Trommel</quote +> auf C#-5 (pitch=61) spielt. </para> + +<para +>Um Map-Dateien in &artscontrol; als Instrumente zur Wahl erscheinen zu lassen, müssen Sie nach der Konvention <filename +>instrument_<replaceable +>irgendetwas</replaceable +>.arts-map</filename +> benannt werden und sich entweder unter Ihrem Persönlichen Verzeichnis in <filename class="directory" +>$<envar +>HOME</envar +>/arts/structures</filename +> oder im &kde;-Verzeichnis unter <filename class="directory" +>$<envar +>KDEDIR</envar +>/share/apps/artsbuilder/examples</filename +> befinden. Strukturen, die von dieser Map verwendet werden, können mit einem absoluten Pfad oder relativ zur Position der Map-Datei angegeben werden. </para> + +<para +>Es ist eine gute Ide, die arts_all.map zu erweitern oder vielleicht sogar eine General-&MIDI;-Map für &arts; zu erstellen. Das würde die Verwendung von &arts; vereinfachen. Bitte denken Sie darüber nach, ob Sie nicht interessante Instrumente für zukünftige Versionen von &arts; zur Verfügung stellen können. </para> +</sect1> + +<!-- TODO: Maybe helpful + * using an external keyboard + * loopback midi device + +<sect1 id="quick-start"> +<title +>Quick Start</title> + +</sect1> +<sect1 id="internal-details"> +<title +>More Internal Details</title> + +</sect1> + +<sect1 id="other-considerations"> +<title +>Other Considerations</title> + +</sect1> +--> + +</chapter> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/midiintro.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/midiintro.docbook new file mode 100644 index 00000000000..0b18627a426 --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/midiintro.docbook @@ -0,0 +1,16 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE appendix PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<appendix id="midi-introduction"> + +<title +>Einführung in <acronym +>MIDI</acronym +></title> + +<para +>Noch nicht geschrieben. </para> + +</appendix> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/modules.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/modules.docbook new file mode 100644 index 00000000000..b6f6ccf91eb --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/modules.docbook @@ -0,0 +1,1331 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="arts-modules"> +<title +>&arts;-Module</title> + + <sect1 id="modules-introduction"> +<title +>Einleitung</title> + +<para +>Dieses Kapitel beschreibt die Standardmodule von &arts;. Eine der mächtigsten Möglichkeiten von &arts; ist die Kombinierbarkeit von Modulen zu Strukturen, um neue Funktionen wie Effekte und Instrumente zu implementieren. </para> + +<para +>Die Module sind in Kategorien eingeteilt. Synthese-Module werden zur Implementation von <quote +>Verbindungen</quote +> benötigt, die Multimedia-Datenströme für neue Effekte, Instrumente, Mischer und Anwendungen zusammenfügen. Visuelle Module erlauben die Erzeugung einer graphischen Benutzeroberfläche zur Kontrolle der Klangstrukturen, die mit den Synthese-Modulen aufgebaut werden. </para> + +</sect1> + +<sect1 id="synth-modules-reference"> +<title +>Synthese-Modul Referenz</title> + + +<sect2 id="mcat-synth-arithmetic-mixing"> +<title +>Arithmetisch + Mix</title> + + + +<sect3 id="mref-synth-add-sect"> +<title +>Synth_ADD</title> +<anchor id="mref-synth-add"/> + +<mediaobject> +<imageobject> +<imagedata fileref="images/Synth_ADD.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_ADD</phrase +></textobject> +</mediaobject> + +<para +>Addiert zwei Signale </para> + +</sect3> + +<sect3 id="mref-synth-mul-sect"> +<title +>Synth_MUL</title> +<anchor id="mref-synth-mul"/> + +<mediaobject> +<imageobject> +<imagedata fileref="images/Synth_MUL.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_MUL</phrase +></textobject> +</mediaobject> + +<para +>Multiplizert ein Signal mit einem Faktor. Sie können dieses Modul verwenden, um ein Signal zu reduzieren (0 < Faktor < 1) oder zu verstärken (Faktor > 1), oder um ein Signal zu invertieren (Faktor < 0). Der Faktor kann ebenfalls ein Signal sein und muss keine Konstante sein (z.B. eine Hüllkurve oder ein reales Signal). </para> + +</sect3> + +<sect3 id="mref-synth-div-sect"> +<title +>Synth_DIV</title> +<anchor id="mref-synth-div"/> + +<mediaobject> +<imageobject> +<imagedata fileref="images/Synth_DIV.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_DIV</phrase +></textobject> +</mediaobject> + +<para +>Dieses Modul teilt ein Signal durch einen Faktor. Es kann verwendet werden, um ein Signal durch ein anderes zu dividieren. Es kann aber auch invalue1 auf 1 gesetzt werden, damit das reziproke von invalue2 als outvalue erscheint. Allerdings darf dann invalue2 nicht 0 werden, da es sonst eine Division durch Null Probleme bereitet. </para> + +</sect3> + +<sect3 id="mref-synth-multi-add-sect"> +<title +>Synth_MULTI_ADD</title> +<anchor id="mref-synth-multi-add"/> + +<mediaobject> +<imageobject> +<imagedata fileref="images/Synth_MULTI_ADD.png" + format="PNG"/></imageobject> +<textobject +><phrase +>Synth_MULTI_ADD</phrase +></textobject> +</mediaobject> + +<para +>Addiert eine beliebige Anzahl von Signalen. Wenn Sie die Wellenformen von vier verschiedenen Oszillatoren addieren müssen, können Sie alle Ausgänge mit einem Synth_MULTI_ADD-Modul verbinden. Das ist effektiver als die Verwendung von drei Synth_ADD-Modulen. </para> + +</sect3> + +<sect3 id="mref-synth-xfade-sect"> +<title +>Synth_XFADE</title> +<anchor id="mref-synth-xfade"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_XFADE.png" format="PNG"/> +</imageobject> +<textobject +><phrase +>Synth_XFADE</phrase +></textobject> +</mediaobject> + +<para +>Hiermit werden zwei Signale über Kreuz gemischt (crossfading). Wenn der Prozentsatz -1 beträgt, dann ist nur das linke, bei 1 nur das rechte und bei 0 sind beide Signale gleichstark hörbar. </para> + +<para +>Damit wird es möglich, ein Signal in einem definierten Bereich zu halten. Wenn Sie zwei Signale haben, die beide zwischen -1 und 1 vor dem Mischen waren, befindet sich das gemischte Signal ebenfalls zwischen -1 und 1. </para> +</sect3> + +<sect3 id="mref-synth-autopanner-sect"> +<title +>Synth_AUTOPANNER</title> +<anchor id="mref-synth-autopanner"/> + +<para +>Das Gegenteil eines crossfaders. Hier wird ein Monosignal aufgeteilt in ein Stereosignal: Das Modul kann das Signal automatisch zwischen dem rechten und linken Kanal aufteilen. Das macht lebendigere Mischungen möglich. Eine Standardanwendung wäre ein Gitarren- oder Gesangsklang. </para> + +<para +>Verbinden Sie einen <acronym +>LFO</acronym +>, eine Sinus- oder Sägezahnschwingung mit inlfo und wählen Sie eine Frequenz zwischen 0.1 und 5Hz für einen traditionellen Effekt oder eine höhere Frequenz für einen Special <acronym +>FX</acronym +>. </para> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-busses"> +<title +>Busse</title> + +<sect3 id="mref-synth-bus-uplink-sect"> +<title +>Synth_BUS_UPLINK</title> +<anchor id="mref-synth-bus-uplink"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_BUS_UPLINK.png" + format="PNG"/> +</imageobject> +<textobject +><phrase +>Synth_BUS_UPLINK</phrase +></textobject> +</mediaobject> + +<para +>Ein Uplink zu einem Bus. Legen Sie ein Signal auf den linken und rechten Eingang und geben Sie dem <quote +>Bus</quote +> einen Namen, auf den die Daten gesendet werden sollen. Das kombinierte Signal von allen Uplinks mit dem gleichen Namen wird auf jedem Downlink mit diesem Namen anliegen. </para> +</sect3> + +<sect3 id="mref-synth-bus-downlink-sect"> +<title +>Synth_BUS_DOWNLINK</title> +<anchor id="mref-synth-bus-downlink"/> + +<mediaobject> +<imageobject> +<imagedata fileref="images/Synth_BUS_DOWNLINK.png" + format="PNG"/></imageobject> +<textobject +><phrase +>Synth_BUS_DOWNLINK</phrase +></textobject> +</mediaobject> + +<para +>Empfängt (Summe) alle Daten, die auf einen bestimmten Bus (der Name, den Sie beim Kanal <quote +>bus</quote +> festlegen) gesendet werden. </para> +</sect3> + +</sect2> + +<!-- TODO AFTER KDE2.1: move freeverb into delays, and rename category to + Delays & reverbs --> + +<sect2 id="mcat-synth-delays"> +<title +>Verzögerungen</title> + + + +<sect3 id="mref-synth-delay-sect"> +<title +>Synth_DELAY</title> +<anchor id="mref-synth-delay"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_DELAY.png" + format="PNG"/></imageobject +></mediaobject> + +<para +>Verzögert das Eingangssignal um eine bestimmte Zeit. Die Zeit muss zwischen 0 und maxdelay für eine Verzögerung zwischen 0 und maxdelay Sekunden liegen. </para> + +<para +>Diese Art von Verzögerungen darf <emphasis +>nicht</emphasis +> in rückgekoppelten Strukturen verwendet werden, weil es sich um eine variable Verzögerungszeit handelt. Sie können die Zeit ändern, während das Modul läuft und sie auch auf Null setzen. Da aber in einer rückgekoppelten Struktur das eigene Ausgangssignal für die Berechnung des nächsten Eingangssignals notwendig ist, könnte eine Verzögerung, die auf Null abfällt, zu einem Einfrieren führen. </para> + +<para +>In einem solchen Fall können Sie aber CDELAY verwenden. Nehmen Sie eine geringe konstante Verzögerung (z.B. 0.001 Sekunden) zusammen mit einer einstellbaren Verzögerung. </para> + +<para +>Außerdem können Sie CDELAY und DELAY kombinieren, um eine variable Verzögerung mit einem positiven Minimalwert in einem rückgekoppelten System zu erhalten. Wichtig ist nur, das ein CDELAY-Modul vorhanden ist. </para> + +</sect3> + +<sect3 id="mref-synth-cdelay-sect"> +<title +>Synth_CDELAY</title> +<anchor id="mref-synth-cdelay"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_CDELAY.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_CDELAY</phrase +></textobject> +</mediaobject> + +<para +>Verzögert das Eingangssignal um eine bestimmte Zeitspanne. Die Zeit muss größer als 0 für eine Verzögerung von mehr als 0 Sekunden sein. Die Verzögerung ist konstant während der Berechnung, kann also nicht verändert werden. </para> + +<para +>Das spart Rechenzeit, da keine Interpolation notwendig ist, und ist nützlich für rekursive Strukturen.Siehe weiter oben (Synth_DELAY). </para> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-envelopes"> +<title +>Hüllkurven</title> + + + +<sect3 id="mref-synth-envelope-adsr-sect"> +<title +>Synth_ENVELOPE_ADSR</title> +<anchor id="mref-synth-envelope-adsr"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_ENVELOPE_ADSR.png" + format="PNG"/></imageobject> +<textobject +><phrase +>Synth_ENVELOPE_ADSR</phrase +></textobject> +</mediaobject> + +<para +>Dies ist eine klassische <acronym +>ADSR</acronym +>-Hüllkurve, das heißt Sie können folgendes festlegen: </para> + +<variablelist> +<varlistentry> +<term +>active</term> +<listitem> +<para +>Ob die Taste gerade vom Benutzer gedrückt wird. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>invalue</term> +<listitem> +<para +>Das Eingangssignal. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>attack</term> +<listitem> +<para +>Die Zeit zwischen dem Niederdrücken der Taste und dem Zeitpunkt zu dem das Signal seine maximale Amplitude erreicht (in Sekunden). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>decay</term> +<listitem> +<para +>Die Zeit, bis das Signal nach dem Maximalwert einen konstanten Dauerwert annimmt (in Sekunden). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>sustain</term> +<listitem> +<para +>Der konstante Dauerwert, bei dem das Signal gehalten wird, nachdem der Benutzer die Taste wieder losgelassen hat. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>release</term> +<listitem> +<para +>Die Zeit vom Loslassen der Taste bis das Signal den Wert Null wiedererreicht hat (in Sekunden). </para> +</listitem> +</varlistentry> +</variablelist> + +<para +>Das skalierte Signal liegt am Ausgang (outvalue) an. Wenn die <acronym +>ADSR</acronym +>-Hüllkurve beendet ist, wird der Ausgang done auf 1 gesetzt. Das können Sie verwenden, um für ein Instrument das Signal <quote +>done</quote +> zu generieren (das dazu führt, das die Struktur vom &MIDI;-Router nach dem Ende der Release-Phase gelöscht wird). </para> + +</sect3> + +<sect3 id="mref-synth-pscale-sect"> +<title +>Synth_PSCALE</title> +<anchor id="mref-synth-pscale"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_PSCALE.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_PSCALE</phrase +></textobject> +</mediaobject> + +<para +>Das Synth_PSCALE-Modul skaliert einen Audiostrom von der Lautstärke 0 (Stille) bis 1 (Maximallautstärke) und zurück zu 0 (Stille). Gesteuert wird das durch den Eingang Position (pos) (dieser Eingang kann mit dem entsprechenden Ausgang von Synth_SEQUENCE belegt werden). Die Stelle, an der der Maximalwert erreicht werden soll, kann als Eingang pos angegeben werden. </para> + +<para +>Beispiel: Setzen Sie top auf 0.1. Das bedeutet, nach 10% der Note erreicht die Lautstärke ihren Maximalwert und klingt danach aus. </para> +</sect3> + +</sect2> + +<sect2 id="mcat-synth-effects"> +<title +>Effekte</title> + +<sect3 id="mref-synth-freeverb-sect"> +<title +>Synth_FREEVERB</title> +<anchor id="mref-synth-freeverb"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_FREEVERB.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_FREEVERB</phrase +></textobject> +</mediaobject> + +<para +>Dies ist ein Nachhall-Effekt. In der augenblicklichen Implementation kann ein Stereosignal durch diesen Effekt geschickt werden. Dabei wird der Nachhall zum ursprünglichen Signal addiert. </para> + +<note> +<para +>Das bedeutet, Sie können das Modul ein innerhalb eines Stereo-Effektstapels verwenden. </para> +</note> + +<para +>Das Eingangssignal wird mit inleft und inright verbunden, das Ausgangssignal liegt bei outleft und outright an. </para> + +<para +>Sie können folgende Parameter festlegen: </para> + +<variablelist> +<varlistentry> +<term +>roomsize</term> +<listitem> +<para +>Die Größe des Raumes, für den der Nachhall simuliert wird (Bereich: 0..1, wobei 1 demgrößtmöglichen Raum entspricht). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>damp</term> +<listitem> +<para +>Dies steuert einen Filter, der die Raumsimulation hohe Frequenzen absorbieren lässt. Der Bereich liegt zwischen 0 (keine Absorption) und 1 (sehr viel Absorption der hohen Frequenzen). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>wet</term> +<listitem> +<para +>der Anteil des Nachhall-Signals (das ist der Anteil des Signals, das durch die Filter verändert und zu einer <quote +>nicht trockenen</quote +> Akustik, also einem <quote +>halligen Klang</quote +> führt. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>dry</term> +<listitem> +<para +>der Anteil des ursprünglichen Signals, der durchgelassen werden soll. Er führt eher zu einem Echo (oder kombinierter Verzögerung) anstatt einem Nachhall-Effekt (Bereich: 0..1) </para> +<!-- TODO: do some measurements to show that this documentation -is- correct, +I am not sure if it is echo, or really pure (non-delayed), or multiple delay +or whatever --> +</listitem> +</varlistentry> + +<varlistentry> +<term +>width</term> +<listitem> +<para +>Der Anteil an Stereo-Magie, den der Nachhall-Effekt hinzufügt und zu einem breiteren Klang im Stereo-Panorama führt (Bereich: 0..1). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>mode</term> +<listitem> +<para +>[ TODO: Ich glaube, wenn mode 1 ist, wird das ursprüngliche Klangbild beibehalten, während mode 0 der normale Arbeitsmodus ist ] </para> +</listitem> +</varlistentry> +</variablelist> + +</sect3> + +<sect3 id="mref-synth-tremolo-sect"> +<title +>Synth_TREMOLO</title> +<anchor id="mref-synth-tremolo"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_TREMOLO.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_TREMOLO</phrase +></textobject> +</mediaobject> + +<para +>Das Tremolo-Modul verändert die Amplitude entsprechend einer <acronym +>LFO</acronym +>-Welle. Üblicherweise verwendet man dazu eine Sinusschwingung, aber das ist nicht zwingend notwendig. Man erhält einen intensiven Effekt, der in vielen Arrangements wegen seiner großen Dynamik sehr durchdringend ist. Der Tremolo-Effekt ist einer der liebsten Effekte für Gittaristen, wenn er auch nicht mehr so populär wie in den 1960ern ist. </para> + +<para +>[TODO: augenblicklich ist dieser Effekt als invalue + abs(inlfo) implementiert - vielleicht wäre es sinnvoller, diesen als invalue * (1+inlfo*depth) zu implementieren, wobei depth den Bereich 0..1 hat - das wird nach KDE2.1 entschieden. Falls Sie Anmerkungen haben, schicken Sie eine Mail an die &arts;-Liste ;). ] </para> + +</sect3> +<sect3 id="mref-synth-fx-cflanger-sect"> +<title +>Synth_FX_CFLANGER</title> +<anchor id="mref-synth-fx-cflanger"/> + +<mediaobject +><imageobject +><imagedata +fileref="images/Synth_FX_CFLANGER.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_FX_CFLANGER</phrase +></textobject> +</mediaobject> + +<para +>Ein Flanger ist ein zeitveränderlicher Verzögerungseffekt. Um die Entwicklung von umfangreichen Flanger-Effekten einfacher zu gestalten, wurde dieses Modul hinzugefügt, das den Kern eines Ein-Kanal-Flangers darstellt. </para> + +<para +>Folgende Kanäle sind vorhanden:</para> + +<variablelist> +<varlistentry> +<term +>invalue</term> +<listitem> +<para +>Das Signal, das verarbeitet werden soll. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>lfo</term> +<listitem> +<para +>Möglichst eine Sinusschwingung, die die Verzögerungszeit (delay) innerhalb des Flangers moduliert (-1 .. 1). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>mintime</term> +<listitem> +<para +>Der minimale Wert für die Verzögerung (delay) innerhalb des Flangers in Millisekunden. Empfohlene Werte: versuchen sie etwa 1 ms. Bitte verwenden Sie Werte < 1000 ms. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>maxtime</term> +<listitem> +<para +>Der minimale Wert für die Verzögerung (delay) innerhalb des Flangers in Millisekunden. Empfohlene Werte: versuchen sie etwa 5 ms. Bitte verwenden Sie Werte < 1000 ms. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>outvalue</term> +<listitem> +<para +>Das Ausgangssignal. Für den Effekt ist es wichtig, dass dieses Signal mit dem ursprünglichen (nicht veränderten) Signal gemischt wird. </para> +</listitem> +</varlistentry> +</variablelist> + +<tip> +<para +>Sie können dieses als die Basis für einen Choreffekt verwenden. </para> +</tip> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-filters"> +<title +>Filter</title> + +<sect3 id="mref-synth-pitch-shift-sect"> +<title +>Synth_PITCH_SHIFT</title> +<anchor id="mref-synth-pitch-shift"/> + +<mediaobject +><imageobject +><imagedata +fileref="images/Synth_PITCH_SHIFT.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_PITCH_SHIFT</phrase +></textobject> +</mediaobject> + +<para +>Dieser Höhenverschiebungseffekt verändert die Frequenz des Eingangssignals ohne die Geschwindigkeit des Signals zu verändern. Eine Anwendung für diesen Effekt ist die Veränderung Ihrer Stimme, während Sie sie aufnehmen (und abspielen) in Echtzeit </para> + +<para +>Der Parameter <emphasis +>speed</emphasis +> gibt die relative Geschwindigkeit wieder, mit der das Signal wiedergegeben wird. Eine Geschwindigkeit von 2 würde den Klang auf die doppelte Frequenz anheben (z.B. würde eine Eingangsfrequenz von 440Hz zu einer Ausgangsfrequenz von 880Hz führen). </para> + +<para +>Der Parameter <emphasis +>frequency(Frequenz)</emphasis +> wird intern verwendet, um zwischen unterschiedlichen Signalgüten umzuschalten. Abhängig von Ihrer Wahl wird der erzeugte Klang mehr oder weniger realistisch sein. Ein guter Startwert liegt zwischen 5 und 10. </para> + +</sect3> + +<sect3 id="mref-synth-shelve-cutoff-sect"> +<title +>Synth_SHELVE_CUTOFF</title> +<anchor id="mref-synth-shelve-cutoff"/> + +<mediaobject +><imageobject +><imagedata +fileref="images/Synth_SHELVE_CUTOFF.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_SHELVE_CUTOFF</phrase +></textobject> +</mediaobject> + +<para +>Filtert alle Frequenzen oberhalb einer Grenzfrequenz heraus. </para> + +</sect3> + +<sect3 id="mref-synth-brickwall-limiter-sect"> +<title +>Synth_BRICKWALL_LIMITER</title> +<anchor id="mref-synth-brickwall-limiter"/> + +<mediaobject +><imageobject +><imagedata +fileref="images/Synth_BRICKWALL_LIMITER.png" + format="PNG"/></imageobject> +<textobject +><phrase +>Synth_BRICKWALL_LIMITER</phrase +></textobject> +</mediaobject> + +<para +>Dieses Modul beschneidet ein Signal, um es in den Bereich von [-1;1] einzupassen. Es werden keine Maßnahmen gegen die Störungen getroffen, die beim Abschneiden lauter Signale entstehen. Sie können das als Effekt verwenden (z.B. um eine leicht abgeschnittene Sinusschwingung zu erzeugen). Es ist wahrscheinlich meistens eine gute Idee, das Resultat durch einen Tiefpassfilter zu schicken, damit es nicht so aggressiv klingt. </para> +</sect3> + +<sect3 id="mref-synth-std-equalizer-sect"> +<title +>Synth_STD_EQUALIZER</title> +<anchor id="mref-synth-std-equalizer"/> + +<mediaobject +><imageobject +><imagedata +fileref="images/Synth_STD_EQUALIZER.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_STD_EQUALIZER</phrase +></textobject> +</mediaobject> + +<para +>Ein hübsches Modul eines parametrischen Equalizers. Folgende Parameter sind vorhanden: </para> + +<variablelist> +<varlistentry> +<term +>invalue, outvalue</term> +<listitem> +<para +>Das Signal, das durch den Equalizer gefiltert wird. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>low</term> +<listitem> +<para +>Wie tiefe Frequenzen verändert werden sollen. Der Wert ist in dB, wobei 0 keine Änderung der tiefen Frequenzen bedeutet, -6 bedeutet Absenkung um 6dB und +6 bedeutet Anhebung um 6dB. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>mid</term> +<listitem> +<para +>Wie mittlere Frequenzen durch den Equalizer verändert werden sollen in dB (siehe auch low). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>high</term> +<listitem> +<para +>Wie hohe Frequenzen durch den Equalizer verändert werden sollen in dB (siehe auch low). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>frequency</term> +<listitem> +<para +>Dies ist die zentral Frequenz des Equalizers in Hz, die mittleren Frequenzen befinden sich in diesem Bereich, die hohen und tiefen Frequenz oberhalb und unterhalb. Anmerkung: die Frequenz kann nicht höher als die halbe Samplingrate sein, also normalerweise 22050Hz, und nicht tiefer als 1 Hz. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>q</term> +<listitem> +<para +>Beeinflusst die Breite des Frequenzspektrums. Es sind nur positive Zahlen > 0 erlaubt. Der Wert Eins ist sinnvoll, höhere Werte von q bedeuten ein schmaleres Frequenzband der mittleren Frequenzen, geringere Werte ein breiteres Band. </para> +</listitem> +</varlistentry> +</variablelist> + +</sect3> + +<sect3 id="mref-synth-rc-sect"> +<title +>Synth_RC</title> +<anchor id="mref-synth-rc"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_RC.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_RC</phrase +></textobject> +</mediaobject> + +<para +>Ein gedämpfter Schwingkreis, der alle Frequenzen um seine Resonanzfrequenz filtert. Es gibt keine leichte Möglichkeit, die Resonanzfrequenz festzulegen (die nicht herausgefiltert wird), da es nur zwei ungewöhnliche Konstanten f und b gibt. Der Programmteil stammt noch aus den ersten Tagen von Synthesizern und wird vermutlich durch einen neuen Filter ersetzt werden, bei dem man die Frequenz und den Resonanzwert als Parameter hat. </para> + +<para +>Versuchen Sie etwa b=5, f=5 oder b=10, f=10 oder b=15, f=15. </para> + +</sect3> + +<sect3 id="mref-synth-moog-vcf-sect"> +<title +>Synth_MOOG_VCF</title> +<anchor id="mref-synth-moog-vcf"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_MOOG_VCF.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_MOOG_VCF</phrase +></textobject> +</mediaobject> + +<para +>Filtert alle Frequenzen oberhalb einer Grenzfrequenz heraus (es handelt sich um einen 24db 4pole-Filter, der -24db pro Oktave oberhalb der Grenzfrequenz absenkt), es gibt einen zusätzlichen Parameter, um die Resonanz einzustellen, 0 bedeutet keine Resonanz und 4 bedeutet selbstoszillierend. </para> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-midi-sequencing"> +<title +>Midi + Sequenzer</title> + +<sect3 id="mref-synth-midi-test-sect"> +<title +>Synth_MIDI_TEST</title> +<anchor id="mref-synth-midi-test"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_MIDI_TEST.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_MIDI_TEST</phrase +></textobject> +</mediaobject> + +<para +>Dieses Modul lädt eine Instrumentenstruktur aus einer Datei und registriert sich als &MIDI;-Ausgangskanal beim &arts;-&MIDI;-Manager. Noten, die an diesen Ausgang gesendet werden, erzeugen Töne dieses Instrumentes. </para> + +<note> +<para +>Sie können so etwas mit &artscontrol; leichter einrichten als manuell in &arts-builder;. </para> +</note> + +</sect3> + +<sect3 id="mref-synth-sequence-sect"> +<title +>Synth_SEQUENCE</title> +<anchor id="mref-synth-sequence"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_SEQUENCE.png" +format="PNG"/></imageobject +></mediaobject> + +<para +>Spielt eine Sequenz von Noten immer wieder. Die Noten werden in Tracker Notation angegeben und durch Semikolons voneinander getrennt. Ein Beispiel ist <literal +>A-3;C-4;E-4;C-4;</literal +>. Die Geschwindigkeit wird in Sekunden pro Note angegeben, wenn Sie also 120 BPM anvisieren, legen Sie die Geschwindigkeit auf 0.5 Sekunden fest, da 60 Sekunden / 0.5 Sekunden pro Note auf 120 BPM führt. </para> + +<para +>Sie können für jede Note eine individuelle Länge relativ zur Grundlänge festlegen durch einen Doppelpunkt gefolgt von der Länge hinter der Notenbezeichnung. Ein Beispiel dafür ist <literal +>A-3:2;C-4:0.5;D-4:0.5;E-4;</literal +>. Midi-Kompositionsprogramme ist ein wenig komfortabler ;) </para> + +<para +>Das Synth_SEQUENCE-Modul gibt zusätzliche Informationen über die Position innerhalb der gerade wiedergegebenen Note aus, wobei 0 gerade begonnen und 1 gerade beendet bedeutet. Diese Informationen können im Synth_PSCALE-Modul verwendet werden (siehe unten). </para> +</sect3> + +<sect3 id="mref-synth-sequence-freq-sect"> +<title +>Synth_SEQUENCE_FREQ</title> +<anchor id="mref-synth-sequence-freq"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_SEQUENCE_FREQ.png" +format="PNG"/></imageobject +></mediaobject> + +<para +>Dieses Modul arbeitet gleich dem Synth_SEQUENCE, einziger Unterschied ist, das es keine Notennamen, sondern Frequenzen annimmt. </para> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-samples"> +<title +>Samples</title> + +<sect3 id="mref-synth-play-wav-sect"> +<title +>Synth_PLAY_WAV</title> +<anchor id="mref-synth-play-wav"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_PLAY_WAV.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_PLAY_WAV</phrase +></textobject> +</mediaobject> + +<para +>Dieser Menüpunkt spielt eine <literal role="extension" +>wav</literal +>-Datei ab. Er ist nur dann verfügbar, wenn Sie libaudiofile auf Ihrem Computer installiert haben. Die wave-Datei startet, sobald das Modul erstellt wird. </para> + +<para +>Sie stoppt, sobald das Ende der wav-Datei erreicht ist. Zusätzlich wird der Parameter finished (beendet) auf 1 gesetzt. Der Geschwindigkeitsparameter (speed) kann verwendet werden, um die Datei schneller oder langsamer wiederzugeben, wobei 1.0 der normalen (aufgenommenen) Geschwindigkeit entspricht. </para> +<!-- TODO: KDE2.2: check that this really works together in instruments with +the done parameter things ;) --> +</sect3> + +</sect2> + +<sect2 id="mcat-synth-soundio"> +<title +>Klang-IO</title> + +<sect3 id="mref-synth-play-sect"> +<title +>Synth_PLAY</title> +<anchor id="mref-synth-play"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_PLAY.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_PLAY</phrase +></textobject> +</mediaobject> + +<important> +<para +>Sie werden dieses Modul normalerweise nicht benötigen, wenn Sie nicht selbstständige Anwendungen erstellen. Innerhalb von &artsd; existiert bereits ein Modul Synth_PLAY und ein zweites wird nicht funktionieren. </para> +</important> + +<para +>Das Synth_PLAY-Modul gibt ein Audio-Signal auf die Soundkarte aus. Die linken und rechten Kanäle sollten die <emphasis +>normalisierten</emphasis +> Eingangssignale für die Kanäle enthalten. Wenn sich das Eingangssignal nicht zwischen -1 und 1 befindet, werden zu hohe Amplituden abgeschnitten (clipping). </para> + +<para +>Wie bereits gesagt, darf es nur ein Synth_PLAY-Modul geben, da es direkt auf die Soundkarte zugreift. Verwenden Sie Busse, wenn Sie mehr als einen Audiostrom mischen wollen. Verwenden Sie das Modul Synth_AMAN_PLAY, um eine Ausgabe innerhalb von &artsd; zu erzeugen. </para> + +<para +>Anmerkung: Das Synth_PLAY-Modul übernimmt das gesamte Timing für die Struktur. Das bedeutet: Wenn Sie kein Synth_PLAY-Modul haben, haben Sie kein Timing und damit auch keine Klangausgabe. Sie benötigen also (genau) ein Synth_PLAY-Objekt. </para> + +</sect3> + +<sect3 id="mref-synth-record-sect"> +<title +>Synth_RECORD</title> +<anchor id="mref-synth-record"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_RECORD.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_RECORD</phrase +></textobject> +</mediaobject> + +<important> +<para +>Sie werden dieses Modul vermutlich niemals benötigen, es sei denn, Sie schreiben selbstständige Anwendungen. Innerhalb von artsd befindet sich bereits ein Synth_RECORD-Modul und ein zweites funktioniert nicht. </para> +</important> + +<para +>Das Synth_RECORD-Modul nimmt ein Signal von Ihrer Soundkarte auf. Die Eingangskanäle left (links) und right (rechts) enthalten die Eingangssignale von der Soundkarte (zwischen -1 und 1). </para> + +<para +>Wie bereits gesagt kann nur ein Synth_RECORD-Modul verwendet werden, da es direkt auf die Soundkarte zugreift. Verwenden Sie Busse, wenn Sie einen Audiodatenstrom an mehr als einer Stelle verwenden möchten. Verwenden Sie das Modul Synth_AMAN_RECORD, um einen Eingang innerhalb von artsd zu erzeugen. Damit das funktioniert, muss &artsd; mit <emphasis +>Full-Duplex aktiviert</emphasis +> gestartet werden. </para> +</sect3> + +<sect3 id="mref-synth-aman-play-sect"> +<title +>Synth_AMAN_PLAY</title> +<anchor id="mref-synth-aman-play"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_AMAN_PLAY.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_AMAN_PLAY</phrase +></textobject> +</mediaobject> + +<para +>Das Modul Synth_AMAN_PLAY gibt ein Ausgangssignal aus. Es sollte (nicht notwendigerweise) normalisiert (zwischen -1 und 1) sein. </para> + +<para +>Dieses Modul verwendet den Audiomanager, um festzulegen, wo das Signal wiedergegeben wird. Der Audiomanager kann mit Hilfe von &artscontrol; gesteuert werden. Um die Verwendung intuitiver zu gestalten, sollten Sie dem Signal einen Namen geben. Das können Sie, indem Sie den Parameter <emphasis +>title (Titel)</emphasis +> verwenden. Eine weitere Besonderheit des Audiomanagers ist die Fähigkeit, den letzten Wiedergabekanal eines Signals zu speichern. Dazu muss er die Signale unterscheiden können. Aus diesem Grund sollten Sie <emphasis +>autoRestoreID</emphasis +> einen eindeutigen Wert geben. </para> +</sect3> + +<sect3 id="mref-synth-aman-record-sect"> +<title +>Synth_AMAN_RECORD</title> +<anchor id="mref-synth-aman-record"/> + +<mediaobject +><imageobject +><imagedata +fileref="images/Synth_AMAN_RECORD.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_AMAN_RECORD</phrase +></textobject> +</mediaobject> + +<para +>Das Modul Synth_AMAN_RECORD kann Daten einer externen Quelle (z.B. Line In / Mikrofon) innerhalb von artsd aufnehmen. Die Ausgabe ist ein normalisiertes Signal (zwischen -1 und 1). </para> + +<para +>Über den Audiomanager kann festgelegt werden, von wo das Signal aufgenommen wird. Der Audiomanager kann mit Hilfe von artscontrol gesteuert werden. Um die Verwendung intuitiver zu gestalten, sollten Sie dem Signal einen Namen geben. Das können Sie, indem Sie den Parameter <emphasis +>title (Titel)</emphasis +> verwenden. Eine weitere Besonderheit des Audiomanagers ist die Fähigkeit, den letzten Wiedergabekanal eines Signals zu speichern. Dazu muss er die Signale unterscheiden können. Aus diesem Grund sollten Sie <emphasis +>autoRestoreID</emphasis +> einen eindeutigen Wert geben. </para> +</sect3> + +<sect3 id="mref-synth-capture-sect"> +<title +>Synth_CAPTURE</title> +<anchor id="mref-synth-capture"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_CAPTURE.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_CAPTURE</phrase +></textobject> +</mediaobject> + +<para +>Das Synth_CAPTURE-Modul kann ein Audiosignal in eine wav-Datei auf Ihrer Festplatte schreiben. Die Datei hat immer den Namen <filename +>/tmp/mcop-<replaceable +>usename</replaceable +>/capture.wav</filename +> </para> +</sect3> + +</sect2> + +<sect2 id="mcat-synth-tests"> +<title +>Tests</title> + +<sect3 id="mref-synth-nil-sect"> +<title +>Synth_NIL</title> +<anchor id="mref-synth-nil"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_NIL.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_NIL</phrase +></textobject> +</mediaobject> + +<para +>Macht gar nichts. Das Modul ist sinnvoll zum Testen. </para> + +</sect3> + +<sect3 id="mref-synth-debug-sect"> +<title +>Synth_DEBUG</title> +<anchor id="mref-synth-debug"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_DEBUG.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_DEBUG</phrase +></textobject> +</mediaobject> + +<para +>Kann zum debuggen verwendet werden. Es gibt den Wert des Signals invalue in gleichbleibenden Abständen (etwa 1 Sekunde) zusammen mit einem von Ihnen festgelegten Kommentar aus. Auf diese Weise können Sie herausfinden, ob gewisse Signale in gewissen Bereichen bleiben oder ob sie überhaupt vorhanden sind. </para> +</sect3> + +<sect3 id="mref-synth-midi-debug-sect"> +<title +>Synth_MIDI_DEBUG</title> +<anchor id="mref-synth-midi-debug"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_MIDI_DEBUG.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_MIDI_DEBUG</phrase +></textobject> +</mediaobject> + +<para +>Hiermit können Sie überprüfen, ob Ihre &MIDI;-Ereignisse &arts; überhaupt erreichen. </para> + +<para +>Wenn ein MIDI_DEBUG aktiv ist, druckt &artsserver; etwa die folgenden Angaben: </para> + +<screen +><computeroutput +>201 100753.837585 on 0 42 127</computeroutput +></screen> + +<screen +><computeroutput +>202 101323.128355 off 0 42</computeroutput +></screen> + +<para +>Die erste Zeile teilt mit, das 100753ms (das sind 100 Sekunden) nach dem Start von MIDI_DEBUG das &MIDI;-Ereignis "Note an" auf Kanal 0 eingetroffen ist.Dieses Ereignis hatte die Lautstärke (velocity) 127, also den lautest möglichen Wert. Die nächste Zeile zeigt das zugehörige "Note aus"-Ereignis.[ TODO: Das funktioniert momentan noch nicht. Reparieren und durch den &MIDI;-Manager leiten]. </para> +</sect3> + +<sect3 id="mref-synth-data-sect"> +<title +>Synth_DATA</title> +<anchor id="mref-synth-data"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_DATA.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_DATA</phrase +></textobject> +</mediaobject> + +<para +>Erzeugt ein Signal mit einer konstanten Nummer. </para> +<!-- TODO: this doesn't really belong in test, does it? --> +</sect3> +</sect2> + +<sect2 id="mcat-synth-osc-mod"> +<title +>Oszillation & Modulation</title> + +<sect3 id="mref-synth-frequency-sect"> +<title +>Synth_FREQUENCY</title> +<anchor id="mref-synth-frequency"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_FREQUENCY.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_FREQUENCY</phrase +></textobject> +</mediaobject> + +<para +>Keiner der Oszillatoren in &arts; benötigt eine Frequenz als Eingabe, sondern nur eine Position innerhalb der Welle. Die Position muss zwischen 0 und 1 liegen. Das wird für ein Standard-Synth_WAVE_SIN-Modul auf den Bereich 0 bis 2*Pi umgerechnet. Um eine bestimmte Frequenz zu erzeugen, benötigen Sie ein Synth_FREQUENCY-Modul. </para> +</sect3> + +<sect3 id="mref-synth-fm-source-sect"> +<title +>Synth_FM_SOURCE</title> +<anchor id="mref-synth-fm-source"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_FM_SOURCE.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_FM_SOURCE</phrase +></textobject> +</mediaobject> + +<para +>Dieses Modul wird für Frequenzmodulation benötigt. Legen Sie die Grundfrequenz an den Frequenzeingang und ein anderes Signal an den Modulationseingang. Setzen Sie den Modulationswert (modlevel) etwa auf 0.3. Die Frequenz wird mit dem Modulationssignal moduliert. Ein interessantes Signal entsteht, wenn man ein rückgekoppeltes Signal verwendet, d.h. eine Kombination des verzögerten Ausgangssignals von Synth_FM_SOURCE (sie müssen es mit einem Oszillator verbinden, da es nur die Rolle von Synth_FREQUENCY übernimmt), und irgendein anderes Signal. </para> + +<para +>Arbeitet gut mit Synth_WAVE_SIN-Oszillatoren zusammen. </para> +</sect3> + +</sect2> + +<sect2 id="mcat-synth-waveforms"> +<title +>Wellenformen</title> + +<sect3 id="mref-synth-wave-sin-sect"> +<title +>Synth_WAVE_SIN</title> +<anchor id="mref-synth-wave-sin"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_WAVE_SIN.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_WAVE_SIN</phrase +></textobject> +</mediaobject> + +<para +>Sinusgenerator. Legen Sie ein Signal (pos) von Synth_FREQUENCY oder Synth_FM_SOURCE an den Eingang und am Ausgang liegt eine Sinusschwingung an. Das pos-Signal legt die Position in der Schwingung (Phasenverschiebung) im Bereich von 0..1 fest, was intern 0..2*Pi entspricht. </para> + +</sect3> + +<sect3 id="mref-synth-wave-tri-sect"> +<title +>Synth_WAVE_TRI</title> +<anchor id="mref-synth-wave-tri"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_WAVE_TRI.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_WAVE_TRI</phrase +></textobject> +</mediaobject> + +<para +>Dreieckgenerator. Legen Sie ein Signal (pos) von Synth_FREQUENCY oder Synth_FM_SOURCE an den Eingang und am Ausgang liegt eine Dreieckschwingung an. Das pos-Signal legt die Position in der Schwingung (Phasenverschiebung) im Bereich von 0..1 fest, was intern 0..2*Pi entspricht. Vorsicht: Das Eingangssignal <emphasis +>muss</emphasis +> im Bereich von 0..1 sein, damit ein gutes Ausgangssignal entsteht. </para> +</sect3> + +<sect3 id="mref-synth-noise-sect"> +<title +>Synth_NOISE</title> +<anchor id="mref-synth-noise"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_NOISE.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_NOISE</phrase +></textobject> +</mediaobject> + +<para +>Lärmgenerator. Dieser Generator erzeugt ein zufälliges Signal zwischen -1 und 1. </para> + +</sect3> + +<sect3 id="mref-synth-wave-square-sect"> +<title +>Synth_WAVE_SQUARE</title> +<anchor id="mref-synth-wave-square"/> + +<mediaobject +><imageobject +><imagedata +fileref="images/Synth_WAVE_SQUARE.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_WAVE_SQUARE</phrase +></textobject> +</mediaobject> + +<para +>Rechteckgenerator. Legen Sie ein Signal (pos) von Synth_FREQUENCY oder Synth_FM_SOURCE an den Eingang und am Ausgang liegt eine Rechteckschwingung an. Das pos-Signal legt die Position in der Schwingung (Phasenverschiebung) im Bereich von 0..1 fest, was intern 0..2*Pi entspricht. Vorsicht: Das Eingangssignal <emphasis +>muss</emphasis +> im Bereich von 0..1 sein, damit ein gutes Ausgangssignal entsteht. </para> +</sect3> + +<sect3 id="mref-synth-wave-softsaw-sect"> +<title +>Synth_WAVE_SOFTSAW</title> +<anchor id="mref-synth-wave-softsaw"/> + +<mediaobject +><imageobject +><imagedata +fileref="images/Synth_WAVE_SOFTSAW.png" format="PNG"/></imageobject> +<textobject +><phrase +>Synth_WAVE_SOFTSAW</phrase +></textobject> +</mediaobject> + +<para +>Abgeschwächte Sägezahnoszillation. Dieses Signal ist ähnlich zum Signal des Dreieckgenerators. Legen Sie ein Signal (pos) von Synth_FREQUENCY oder Synth_FM_SOURCE an den Eingang und am Ausgang liegt eine weiche Sägezahnschwingung an. Das pos-Signal legt die Position in der Schwingung (Phasenverschiebung) im Bereich von 0..1 fest, was intern 0..2*Pi entspricht. Vorsicht: Das Eingangssignal <emphasis +>muss</emphasis +> im Bereich von 0..1 sein, damit ein gutes Ausgangssignal entsteht. </para> +</sect3> + +<sect3 id="mref-synth-wave-pulse-sect"> +<title +>Synth_WAVE_PULSE</title> +<anchor id="mref-synth-wave-pulse"/> + +<mediaobject +><imageobject +><imagedata fileref="images/Synth_WAVE_PULSE.png" +format="PNG"/></imageobject> +<textobject +><phrase +>Synth_WAVE_PULSE</phrase +></textobject> +</mediaobject> + +<para +>Impulsgenerator - dieses Modul ist grundsätzlich ähnlich zum Rechteckgenerator (Synth_WAVE_RECT), bietet aber zusätzlich eine Möglichkeit, das Verhältnis von Maximumzeit zu Minimumzeit mit dem Eingang <emphasis +>dutycycle</emphasis +> einzustellen. Legen Sie ein Signal (pos) von Synth_FREQUENCY oder Synth_FM_SOURCE an den Eingang und am Ausgang liegt eine Impulsschwingung an. Das pos-Signal legt die Position in der Schwingung (Phasenverschiebung) im Bereich von 0..1 fest, was intern 0..2*Pi entspricht. Vorsicht: Das Eingangssignal <emphasis +>muss</emphasis +> im Bereich von 0..1 sein, damit ein gutes Ausgangssignal entsteht. </para> +</sect3> +</sect2> +<sect2 id="mcat-synth-misc"> +<title +>Verschiedenes</title> + +<sect3 id="mref-synth-compressor-sect"> +<title +>Synth_COMPRESSOR</title> +<anchor id="mref-synth-compressor"/> + +<mediaobject> +<imageobject +><imagedata fileref="images/Synth_COMPRESSOR.png" + format="PNG"/></imageobject +></mediaobject> + +<para +>Dieses Modul reduziert den Dynamikbereich des Signals. Ein Kompressor ist nützlich, um die großen Lautstärkeschwankungen einer über ein Mikrophon redenden Person zu verringern. </para> + +<para +>Sobald das Eingangssignal einen bestimmten Pegel (den Grenzpegel) überschreitet, wird der Pegel reduziert. Jeder Pegelwert oberhalb des Grenzpegels wird mit einem Faktor, eine Zahl zwischen 0 und 1, multipliziert. Zum Abschluß wird das gesamte Signal mit dem Ausgangsfaktor multipliziert. </para> + +<para +>Die Argumente attack und release verzögern den Start und das Ende der Kompression. Das kann verwendet werden, um z.B. den lauten Beginn einer Basedrum zu hören. Das Argument wird in Millisekunden angegeben und ein Wert von 0 ms ist möglich, kann aber zu einem leichten Nebengeräusch führen. </para> + +</sect3> +</sect2> +</sect1> + +<sect1 id="visual-modules-reference"> +<title +>Visuelle Modul-Referenz</title> + +<para +>TODO wenn visuelle Module stabiler sind. </para> +</sect1> + +</chapter> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/porting.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/porting.docbook new file mode 100644 index 00000000000..d6579f178bf --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/porting.docbook @@ -0,0 +1,50 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="porting"> +<title +>Anwendungen auf &arts; portieren</title> + +<sect1 id="using-artsdsp"> +<title +>&artsdsp; verwenden</title> + +<para +>Die Anwendung &artsdsp;, die <link linkend="artsdsp" +> weiter oben</link +> beschrieben wird, erlaubt den meisten Standardanwendungen, die direkt auf die Audio-Geräte zugreifen, unter &arts; problemlos zu funktionieren. Die meisten Anwendungen, die den Enlightenment Sound Daemon (esd) verwenden, funktionieren ebenfalls, indem <application +>esd</application +> unter &artsdsp; gestartet wird. </para> + +<para +>Damit existiert eine gute Übergangslösung, um Anwendungen auf &kde; zu portieren. Es erlaubt natürlich keiner Anwendung, direkt von &arts; zu profitieren und alle Fähigkeiten von &arts;, wie z.B. die Verwendung von Modulen und Multimediaströmen, zu verwenden. Wenn die Anwendung mehr können soll, als nur einfache Audiodateien abzuspielen, sollte man Unterstützung für &arts; hinzufügen. </para> + +<para +>Die Anwendung kann dann viele Aufgaben an &arts; übertragen -- sie kann die in &arts; enthaltenen Funktionen verwenden, um Dinge wie unterschiedliche Codecs, Medienformate oder die Kontrolle der Audiogeräte. </para> + +</sect1> + +<sect1 id="adding-native-arts-support"> +<title +>&arts;-Unterstützung hinzufügen</title> + +<para +>Wenn Sie &arts; verwenden, können Sie zwischen verschiedenen <link linkend="arts-apis" +><acronym +>API</acronym +>s</link +> auswählen. Die Entscheidung wird unter anderem davon abhängen, welche Art von Medienstrom (Klang, &MIDI;, &CD;-Audio &etc;) Sie verwenden wollen, welche <acronym +>API</acronym +>-Fähigkeiten Sie benötigen und ob Sie in C++ programmieren. In den meisten Fällen sollte die Entscheidung abhängig von den benötigten Fähigkeiten klar sein </para> + +<para +>Anwendungen, die auf anderen Architekturen als &kde; funktionieren sollen, können nicht davon ausgehen, das &arts; immer vorhanden ist. Durch eine Plugin-Architektur können Sie geschickt verschiedene Multimediaumgebungen unterstützen. Wenn Sie das Plugin-<acronym +>API</acronym +> außerdem veröffentlichen und gut dokumentieren (besonders für nicht als Quelltext verfügbare Anwendungen), ermöglichen Sie auch anderen Entwicklern, ein &arts;-Plugin für Ihre Anwendung zu schreiben. </para> + +</sect1> + +</chapter> + diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/references.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/references.docbook new file mode 100644 index 00000000000..41a070d556a --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/references.docbook @@ -0,0 +1,61 @@ +<!-- <?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="references"> +<title +>Referenz</title> + +<variablelist> + +<varlistentry> +<term +><ulink +url="http://multimedia.kde.org" +>http://multimedia.kde.org</ulink +></term> +<listitem> +<para +>Das ist die Hauptseite für Informationen zum Thema &kde;-Multimedia. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><ulink +url="http://www.arts-project.org" +>http://www.arts-project.org</ulink +></term> +<listitem> +<para +>Das ist die Internetseite des &arts;-Projektes. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>&kde; 2.0 Development (&kde; 2.0 Entwicklung)</term> +<listitem> +<para +>Kapitel 14 dieses veröffentlichten Buches beschäftigt sich mit Multimedia allgemein und mit &arts;. Es ist gedruckt oder im Internet mit Kommentaren verfügbar unter <ulink url="http://www.andamooka.org" +>http://www.andamooka.org</ulink +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term> +<ulink +url="http://sound.condorow.net" +>http://sound.condorow.net</ulink +></term> +<listitem> +<para +>Diese Internetseite hat eine umfangreiche List zu Klängen und &MIDI;-Anwendungen unter &Linux;. </para> +</listitem> +</varlistentry> + +</variablelist> + +</chapter> diff --git a/tde-i18n-de/docs/tdemultimedia/artsbuilder/tools.docbook b/tde-i18n-de/docs/tdemultimedia/artsbuilder/tools.docbook new file mode 100644 index 00000000000..06b47a413dd --- /dev/null +++ b/tde-i18n-de/docs/tdemultimedia/artsbuilder/tools.docbook @@ -0,0 +1,1007 @@ +<!-- +<?xml version="1.0" ?> +<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd"> + +To validate or process this file as a standalone document, uncomment +this prolog. Be sure to comment it out again when you are done --> + +<chapter id="arts-tools"> +<title +>&artscontrol;</title> + +<para +>Mit &arts; werden einige Hilfs- und Steuerprogramme ausgeliefert. Sie müssen sich mit diesen Programmen vertraut machen, wenn Sie &arts; effektiv nutzen wollen. Dieser Abschnitt beschreibt jedes dieser Programme und ihre Aufrufparameter. </para> + +<sect1 id="kde-control-center"> +<title +>&kcontrol;</title> + +<para +>Wenn Sie &arts; unter &kde; einsetzen, stellt &kcc; einige Einstellmöglichkeiten in dem Abschnitt <guilabel +>Klänge</guilabel +> bereit. Einige dieser Einstellungen werden von &arts; verwendet. Weiterhin können Sie Klänge mit verschiedenen Systemnachrichten des Fenstermanagers oder von &kde; im Abschnitt <menuchoice +><guilabel +>Erscheinungsbild</guilabel +><guilabel +>Systemnachrichten</guilabel +></menuchoice +> verknüpfen. Das Handbuch zu &kcontrol; gibt genauere Informationen über diese Einstellungen. </para> + +</sect1> + +<sect1 id="artsd"> +<title +>&artsd;</title> + +<para +>Der Zugriff auf die Klangressourcen wird durch &artsd;, den &arts;-Dämon kontrolliert. Das ermöglicht es verschiedenen Anwendungen, gleichzeitig Anfragen an den Soundserver zu senden, der sie dann mixt und zusammen wiedergibt. Ohne einen zentralen Soundserver kann immer nur eine Anwendung zur Zeit die Klangressourcen verwenden. </para> + +<para +>Zur Verwendung von &arts; darf nur eine Instanz von &artsd; aktiv sein. Sie wird normalerweise beim Start von &kde; gestartet, wenn der zugehörige Eintrag in &kcontrol; im Abschnitt <guilabel +>Soundserver</guilabel +> aktiviert ist. </para> + +<para +>Das Programm akzeptiert die folgenden Aufrufparameter:</para> + +<!-- LW: FIX THIS --> + +<cmdsynopsis +><command +>artsd</command +> <group choice="opt" +> <option +>-n</option +> <option +>-p</option +> <option +>-N</option +> <option +>-W <replaceable +>n</replaceable +></option +> </group +> <group choice="opt" +> <option +>-a <replaceable +>audiomethod</replaceable +></option +> <option +>-r <replaceable +>sampling rate</replaceable +></option +> <option +>-b <replaceable +>bits</replaceable +></option +> <option +>-d</option +> <option +>-D <replaceable +>devicename</replaceable +></option +> <option +>-F <replaceable +>fragments</replaceable +></option +> <option +>-S <replaceable +>size</replaceable +></option +> <option +>-s <replaceable +>seconds</replaceable +></option +> <option +>-m <replaceable +>appName</replaceable +></option +> </group +> <group choice="opt" +> <option +>-h</option +> <option +>-A</option +> <option +>-v</option +> <option +>-l <replaceable +>level</replaceable +></option +> </group +> </cmdsynopsis> + +<variablelist +><varlistentry> +<term +><option +>-r <replaceable +>Sampling-Rate</replaceable +></option +></term> +<listitem> +<para +>Setzt die zu verwendende Sampling-Rate.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-h</option +></term> +<listitem> +<para +>Verwendungshinweise anzeigen.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-n</option +></term> +<listitem> +<para +>Netzwerk-Transparenz aktivieren.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-p <replaceable +>Port</replaceable +></option> +</term> +<listitem> +<para +>Legt den zu verwendenden <acronym +>TCP</acronym +>-Port fest (setzt <option +>-n</option +> voraus).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-u</option +></term> +<listitem> +<para +>Öffentlich, keine Authentifizierung (unsicher).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-d</option +></term> +<listitem> +<para +>Volle Duplex-Fähigkeit aktivieren.</para> +</listitem> +</varlistentry> +<varlistentry> +<term +><option +>-D <replaceable +>Gerätename</replaceable +></option +></term> +<listitem> +<para +>Audiogerät festlegen (normalerweise <filename +>/dev/dsp</filename +>).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-F <replaceable +>Fragmente</replaceable +></option +></term> +<listitem> +<para +>Anzahl der Fragmente festlegen.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-S <replaceable +>Größe</replaceable +></option +></term> +<listitem> +<para +>Legt die Fragmentgröße in Byte fest.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-s <replaceable +>Sekunden</replaceable +></option +></term> +<listitem> +<para +>Legt die Zeit bis zum automatischen Aussetzen in Sekunden fest. Der Wert Null deaktiviert das automatische Aussetzen.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-m <replaceable +>appName</replaceable +></option +></term> +<listitem> +<para +>Gibt den Namen der Anwendung an, die für die Ausgabe von Fehler- , Warn- und Informationsmeldungen verwendet wird. Wenn Sie KDE verwenden, können Sie das Hilfsprogramm <application +>artsmessage</application +> verwenden.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-N</option +></term> +<listitem> +<para +>Erhöht die Größe der Netzwerkpuffer auf einen Wert, der für ein 10 mbps LAN erforderlich ist. Diese Einstellung ist äquivalent zur Option -w 5 (weiter unten). </para> +</listitem> +</varlistentry> +<varlistentry> +<term +><option +>-w <replaceable +>n</replaceable +></option +></term> +<listitem> +<para +>Wenn Sie &artsd; über eine Netzwerkverbindung zu einem anderen Rechner betreiben, sollten Sie die Puffer vergrößern, um Aussetzer zu vermeiden. &arts; stellt Anwendungen eine Standardpuffergröße bereit. Ohne diese Option basiert die Größe auf Abschnittgröße * Abschnittanzahl. Durch diese Option können Sie diese Größe vom Standardwert um einen Faktor von <replaceable +>n</replaceable +> erhöhen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-l <replaceable +>Ebene</replaceable +></option +></term> +<listitem> +<para +>Legt die Informationsebene fest - 3 (keine), 2 (Warnungen), 2 (Informationen), 0 (Debug).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-v</option +></term> +<listitem> +<para +>Versionsnummer anzeigen.</para> +</listitem> +</varlistentry> + +</variablelist> + +<para +>In den meisten Fällen reicht das Kommando &artsd; zum Start. </para> +</sect1> + +<sect1 id="artswrapper"> +<title +>&artswrapper;</title> + +<para +>Für ein gutes Echtzeit-Antwortverhalten, sollte &artsd; normalerweise als Echtzeit-Prozess (auf Systemen, die solche Prozesse unterstützen) gestartet werden. Das erfordert root-Rechte, daher kann &artsd; aus Sicherheitsgründen durch ein kleines Startprogramm namens <application +>artswrapper</application +> gestartet werden, das Echtzeitpriorität setzt (es arbeitet als <systemitem class="username" +>root</systemitem +>) und dann <command +>artsd</command +> als Nicht-root startet. </para> + +<para +>Falls man artswrapper als SUID <systemitem class="username" +>root</systemitem +> ausführt, wird die Qualität der Wiedergabe aufgrund weniger Unterbrechungen der Musik erhöht. Allerdings erhöht sich dadurch auch das Risiko einer Beschädigung des Rechners durch einen Fehler oder einen böswilligen Benutzer. Außerdem kann die Wiedergabe einer hochwertigen Musikaufnahme in einem Mehr-Benutzersystem negative Auswirkungen auf die Geschwindigkeit anderer Prozesse und Benutzer haben, die <quote +>produktiv</quote +> arbeiten wollen.</para> + +</sect1> + +<sect1 id="artsshell"> +<title +>&artsshell;</title> + +<para +>Der Befehl &artsshell; ist ein Hilfsprogramm, das verschiedene Funktionen im Zusammenhang mit dem Soundserver ausführt. Das Programm wird in der Zukunft vermutlich mit weiteren Funktionen ausgestattet (einen Überblick geben die Kommentare im Quelltext). </para> + +<para +>Die Befehlszeile zum Start hat das folgende Format: </para> + +<!-- LW: FIX THIS --> + +<cmdsynopsis +><command +>artsshell</command +> <group +> <arg +>suspend</arg +><arg +>status</arg +> <arg +>terminate</arg +> <arg +>autosuspend <replaceable +>secs</replaceable +></arg +> <arg +>networkbuffers <replaceable +>n</replaceable +></arg +> <arg +>volume [<replaceable +>volume</replaceable +>]</arg +> <arg +>stereoeffect <replaceable +>options</replaceable +></arg +> </group +> <group +> <option +>-h</option +> <option +>-q</option +> </group +> </cmdsynopsis> + +<para +>artsshell [options] <replaceable +>Befehl</replaceable +> [<replaceable +>Befehlsoptionen</replaceable +>] </para> + +<para +>Folgende Optionen werden unterstützt: </para> + +<variablelist> + +<varlistentry> +<term +><option +>-q</option +></term> +<listitem> +<para +>Ausgabe unterdrücken.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-h</option +></term> +<listitem> +<para +>Verwendungshinweise anzeigen.</para> +</listitem> +</varlistentry> + +</variablelist> + +<para +>Folgende Befehle werden unterstützt:</para> + +<variablelist> + +<varlistentry> +<term +><option +>suspend</option +></term> +<listitem> +<para +>Der Soundserver schaltet sich aus. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>status</option +></term> +<listitem> +<para +>Statusinformationen des Soundservers anzeigen.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>terminate</option +></term> +<listitem> +<para +>Den Soundserver beenden. Das kann Programme, die den Soundserver verwenden, zum Absturz bringen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>autosuspend</option +> <parameter +>Sekunden</parameter +></term> +<listitem> +<para +>Setzt die Zeit bis zum Aussetzen auf die angegebene Anzahl von Sekunden. Der Soundserver setzt automatisch aus, wenn er die angegebene Zeit unbeschäftigt ist. Der Wert Null deaktiviert das automatische Aussetzen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>networkbuffers</option +> <parameter +>n</parameter +></term> +<listitem> +<para +>Setzt die Größe der Netzwerkpuffer auf das <parameter +>n</parameter +>-fache der Standardgröße. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>volume</option +> [<replaceable +>Lautstärke</replaceable +>]</term> +<listitem> +<para +>Legt die Lautstärkeskalierung für die Soundserver Audioausgabe fest. Das Argument <replaceable +>Lautstärke</replaceable +> ist eine Kommazahl. Bei Aufruf ohne Argument wird der aktuelle Wert angezeigt. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>Liste der Stereoeffekte</option +></term> +<listitem> +<para +>Liste aller verfügbaren Stereoeffektmodule</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>stereoeffect insert [top|bottom]</option +> <replaceable +>Name</replaceable +></term> +<listitem> +<para +>Fügt einen Stereoeffekt in einen Stereoeffektstapel ein. Gibt einen Namen zurück, der für ein späteres Löschen erforderlich ist. Der Effekt kann oben oder unten (Standardeinstellung) hinzugefügt werden.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>stereoeffect remove</option +> <replaceable +>Id</replaceable +></term> +<listitem> +<para +>Löscht den Stereoeffekt mit dem Namen <replaceable +>Id</replaceable +> vom Effektstapel.</para> +</listitem> +</varlistentry> + +</variablelist> + +</sect1> + +<sect1 id="artsplay"> +<title +><application +>artsplay</application +></title> + +<para +>Der Befehl <application +>artsplay</application +> ist ein einfaches Hilfsprogramm zum Abspielen einer Klangdatei. Der Befehl hat ein einziges Argument, nämlich den Namen der an den Soundserver zu schickenden Datei. Die Klangdatei kann zu jedem der üblichen Typen gehören, also <literal role="extension" +>wav</literal +> oder <literal role="extension" +>au</literal +>. Mit diesem Befehl kann man testen, ob der Soundserver funktioniert. Indem man zwei Befehl parallel oder in schneller Folge gibt, kann man demonstrieren, wie der Soundserver mehrere Ausgaben mixen kann.</para> + +</sect1> + +<sect1 id="artsdsp"> +<title +><application +>artsdsp</application +></title> + +<para +>Der Soundserver unterstützt nur Anwendungen, die &arts;-aktiviert sind. Viele herkömmliche Anwendungen wollen auf die Klanggeräte direkt zugreifen. Das Programm &artsdsp; ist eine Übergangslösung, die es vielen dieser Anwendungen erlaubt, ohne Änderung zu funktionieren. </para> + +<para +>Wenn ein Programm unter &artsdsp; ausgeführt wird, werden alle Zugriffe auf das Audiogerät <filename class="devicefile" +>/dev/dsp</filename +> abgefangen und in &arts; <acronym +>API</acronym +>-Aufrufe umgewandelt. Diese Emulation ist nicht perfekt, aber die meisten Anwendungen funktionieren auf diese Weise mit einer kleinen Einbuße an Geschwindigkeit und Antwortverhalten. </para> + +<para +>Der Befehl &artsdsp; hat das folgende Format: </para> + +<!-- LW: FIX THIS --> +<para +>artsdsp [<replaceable +>Optionen</replaceable +>] <replaceable +>Anwendung Parameter</replaceable +> </para> + +<para +>Folgende Optionen werden erkannt: </para> + +<variablelist> + +<varlistentry> +<term +><option +>-h</option +>, <option +>--help</option +></term> +<listitem> +<para +>Zeigt eine kurze Hilfe.</para> +</listitem> +</varlistentry> +<varlistentry> +<term +><option +>-n</option +> <option +>--name</option +> = <replaceable +>Name</replaceable +></term> +<listitem> +<para +>Verwendet <replaceable +>Name</replaceable +> um den Spieler gegenüber <command +>artsd</command +>.zu identifizieren.</para> + +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-m</option +> <option +>--mmap</option +></term> +<listitem> +<para +>Speicher-Mapping emulieren (&zb; für <application +>Quake</application +>).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-v</option +> <option +>--verbose</option +></term> +<listitem> +<para +>Zeigt Parameter an.</para> +</listitem> +</varlistentry> + +</variablelist> + +<para +>Ein typischer Aufruf ist: </para> + +<para> +<userinput +><command +>artsdsp</command +> <option +>-v</option +> <option +>-m</option +> <parameter +>realplay <replaceable +>Lied.mp3</replaceable +></parameter +></userinput> +</para> + +<para +>Einige Anwendungen funktionieren mit der Einstellung <option +>--mmap</option +> besser. Es werden nicht alle Funktionen des Klanggerätes voll emuliert, aber die meisten Anwendungen sollten funktionieren. Falls eine nicht funktionieren sollte, senden Sie eine detailierte Benachrichtigung ein. So können die Entwickler möglicherweise eine Lösung finden. Bedenken Sie, dass es sich um eine Übergangslösung handelt. Die beste Lösung ist sicherlich, Unterstützung für &arts; zu der Anwendung hinzuzufügen. Wenn Ihre Lieblingsanwendung &arts; nicht unterstützt, bitten Sie die Entwickler diese Unterstützung nachzurüsten. </para> + +</sect1> + +<sect1 id="artscat"> +<title +><application +>artscat</application +></title> + +<para +>Dieses kleine Hilfsprogramm kann Audion-Rohdaten zum Soundserver schicken. Sie müssen das Datenformat (Samplingrate, Samplegröße und Anzahl der Kanäle) angeben. Es ist ein Programm, das Sie vermutlich nicht oft benötigen, das aber für Testzwecke recht praktisch ist. Die Aufrufsyntax ist: </para> + +<!-- LW: FIX THIS --> + +<para +>artscat [ <replaceable +>Optionen</replaceable +> ] [ <replaceable +>Dateiname</replaceable +> ] </para> + +<para +>Wenn Sie keinen Dateinamen angeben, wird von der Standardeingabe gelesen. Folgende Optionen werden unterstützt: </para> + +<variablelist> +<varlistentry> +<term +><option +>-v</option +> <parameter +>--verbose</parameter +></term> +<listitem> +<para +>Setzt die zu verwendende Sampling-Rate. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-b</option +> <parameter +>Bits</parameter +></term> +<listitem> +<para +>Setzt die Sample-Größe fest (8 oder 16). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-c</option +> <parameter +>Kanäle</parameter +></term> +<listitem> +<para +>Setzt die Anzahl der Kanäle fest (1 oder 2). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-h</option +></term> +<listitem> +<para +>Nur Verwendungshinweise anzeigen. </para> +</listitem> +</varlistentry> + +</variablelist> +</sect1> + +<sect1 id="artscontrol"> +<title +>&artscontrol;</title> + +<para +>Dies ist ein graphisches Programm für die Durchführung einer Anzahl Aufgaben im Zusammenhang mit dem Soundserver. Das Hauptfenster hat zwei Lautstärkeanzeigen und einen Schieberegler für die Gesamtausgabelautstärke. Aus dem Menü <guimenu +>Ansicht</guimenu +> können Sie weitere Funktionen auswählen: </para> + +<variablelist> + +<varlistentry> +<term +><guimenuitem +>FFT-Anzeige</guimenuitem +></term> +<listitem> +<para +>Öffnet ein Fenster mit einer Echtzeit-Spektrumanalysator-Anzeige. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>Audio-Manager</guimenuitem +></term> +<listitem> +<para +>Zeigt die aktiven Klangquellen an und erlaubt die Zuordnung zu einem der verfügbaren Busse. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>aRts-Statusanzeige</guimenuitem +></term> +<listitem> +<para +>Zeigt an, ob der Soundserver läuft und Echtzeitpriorität besitzt. Außerdem wird angezeigt, wann der Soundserver automatisch aussetzt. Durch einen Knopf kann er auch sofort ausgeschaltet werden. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>Midi-Manager</guimenuitem +></term> +<listitem> +<para +>Zeigt aktive &MIDI;-Ein- und Ausgabegeräte an und erlaubt die Herstellung von Verknüpfungen [TODO: Funktioniert vermutlich noch nicht! Mehr Details benötigt]. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>FreeVerb</guimenuitem +></term> +<listitem> +<para +>Verbindet einen FreeVerb-Echoeffekt mit dem Stapel von &arts; Ausgabeeffekten und erlaubt eine graphische Kontrolle der Effektparameter. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>Lautstärkeanzeige im LED-Stil</guimenuitem +></term> +<listitem> +<para +>Ändert die Lautstärkeanzeige des Hauptfensters auf eine farbige <acronym +>LED</acronym +>-Anzeige anstatt Fortschrittsbalken. </para> +</listitem> +</varlistentry> + +</variablelist> + +</sect1> + +<sect1 id="artsc-config"> +<title +><application +>artsc-config</application +></title> + +<para +>Dieses Hilfsprogramm unterstützt Entwickler bei der Verwendung des &arts; C-<acronym +>API</acronym +>. Es gibt die geeignete Compiler- und Linker-Optionen aus, die zur Kompilierung und zum Linken von Programmen mit &arts; benötigt werden. Es ist gedacht zur Verwendung innerhalb von make-Dateien zur Unterstützung von Portabilität. Das Programm kennt drei Optionen: </para> + +<variablelist> +<varlistentry> +<term +><option +>--cflags</option +></term> +<listitem> +<para +>Zeigt die Kompiler-Flags an, die zur Kompilierung mit dem &arts; C-<acronym +>API</acronym +> benötigt werden. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>--libs</option +></term> +<listitem> +<para +>Zeigt die Linker-Flags an, die zum Linken mit dem &arts; C-<acronym +>API</acronym +> benötigt werden. </para> +</listitem> +</varlistentry> +<varlistentry> +<term +><acronym +>--version</acronym +></term> +<listitem> +<para +>Zeigt die Versionsnummer des <command +>artsc-config</command +> Befehles an. </para> +</listitem> +</varlistentry> +</variablelist> + +<para +>Eine typische Ausgabe dieses Befehls sieht folgendermaßen aus:</para> + +<screen width="40" +><prompt +>%</prompt +> <userinput +><command +>artsc-config</command +> <option +>--cflags</option +></userinput> +<computeroutput +>-I/usr/local/kde2/include/artsc</computeroutput> +<prompt +>%</prompt +> <userinput +><command +>artsc-config</command +> <option +>--libs</option +></userinput> +<computeroutput +>-L/usr/local/kde2/lib -ldl -lartsc -DPIC -fPIC -lpthread</computeroutput> +<prompt +>%</prompt +> <userinput +><command +>artsc-config</command +> <option +>--version</option +></userinput> +<computeroutput +>0.9.5</computeroutput +> +</screen> + +<para +>Sie können dieses Programm in einer Make-Datei z.B. in einer solchen Regel verwenden: </para> + +<programlisting +>artsc: artsc.c + gcc `artsc-config --cflags` -o artsc artsc.c `artsc-config --libs` +</programlisting> + +</sect1> + +<sect1 id="mcopidl"> +<title +>&mcopidl;</title> + +<para +>Der Befehl &mcopidl; ist der <acronym +>IDL</acronym +>-Datei Kompiler für &MCOP;, das Multimedia Communication Protokol, das von &arts; verwendet wird. Interfaces sind in &arts; in &IDL;, einer sprachunabhängigen Interface Definition Language, geschrieben. Das Programm &mcopidl; akzeptiert ein &IDL;-Datei als Eingabe und generiert C++-Header und Quelldateien für eine Klasse, die das Interface implementiert. Der Befehl hat die folgende Syntax: </para> + +<!-- LW: FIX THIS --> + +<para +>mcopidl [ <replaceable +>Optionen</replaceable +> ] <replaceable +>Dateiname</replaceable +> </para> + +<para +>Folgende Optionen sind möglich:</para> +<variablelist> +<varlistentry> +<term +><option +>-I</option +> <parameter +>Verzeichnis</parameter +></term> +<listitem> +<para +>Suche in <parameter +>Verzeichnis</parameter +> nach Include-Dateien. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-e</option +> <parameter +>Name</parameter +></term> +<listitem> +<para +>Schließe die Struktur, das Interface oder den Aufzählungstyp <parameter +>Name</parameter +> von der Erzeugung aus. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-t</option +></term> +<listitem> +<para +>Erzeuge zusätzlich die Dateien <literal role="extension" +>.mcoptype</literal +>/ <literal role="extension" +>.mcopclass</literal +>, die Informationen für die &IDL;-Datei enthalten. </para> +</listitem> +</varlistentry> +</variablelist> + +<para +>Weitere Informationen über &MCOP; und &IDL; finden Sie im Abschnitt <link linkend="interfaces" +>Interfaces und &IDL;</link +>. </para> + +</sect1> + +</chapter> |