diff options
Diffstat (limited to 'tde-i18n-da/docs/tdemultimedia/artsbuilder')
20 files changed, 10880 insertions, 0 deletions
diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/Makefile.am b/tde-i18n-da/docs/tdemultimedia/artsbuilder/Makefile.am new file mode 100644 index 00000000000..29f2e0115ae --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/Makefile.am @@ -0,0 +1,4 @@ +KDE_LANG = da +SUBDIRS = $(AUTODIRS) +KDE_DOCS = AUTO +KDE_MANS = AUTO diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/Makefile.in b/tde-i18n-da/docs/tdemultimedia/artsbuilder/Makefile.in new file mode 100644 index 00000000000..1bb68808ae4 --- /dev/null +++ b/tde-i18n-da/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 = da +#>- 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-da/docs/tdemultimedia/artsbuilder/apis.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/apis.docbook new file mode 100644 index 00000000000..0ad1a4d2332 --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/apis.docbook @@ -0,0 +1,424 @@ +<!-- <?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; programmeringsgrænseflade</title> + +<sect1 id="api-overview"> +<title +>Oversigt</title> +<para +>aRts er ikke kun et program, den sørger for også et antal forskellige programmeringsgrænseflader (API) til forskellige formål. I dette afsnit, forsøger jeg at beskrive "helhedsbilledet", et hurtigt overblik over hvad disse grænseflader er tænkte at bruges til, og hvordan de hænger sammen. </para> + +<para +>Der er en vigtig distinktion som skal gøres: De fleste grænseflader er <emphasis +> sprog- og pladsuafhængige</emphasis +> eftersom de er specificerede som <emphasis +>mcopidl</emphasis +>. Dette betyder at man egentlig kan bruge den tjeneste de sørger for fra et hvilket som helst sprog, implementere dem i et hvilket som helst sprog, og man behøver ikke tage sig af om man taler med lokal- eller fjernobjekter. Her er først en liste af dem: </para> + + +<variablelist> +<varlistentry> +<term +>core.idl</term> + <listitem +><para +>Grundlæggende definitioner som danner kernen i MCOP-funktionen, såsom selve protokollen, definitioner af objekter, handleren, flowsystemet og så videre. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsflow.idl</term> + + <listitem +><para +>Disse indeholder flowsystemet som man bruger til at forbinde lydstrømmene, definitionen af <emphasis +>Arts::SynthModule</emphasis +> som er grundlaget for alle grænseflade som har strømme, og til slut nogle nyttige lydobjekter. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>kmedia2.idl</term> + + + <listitem +><para +>Her defineres <emphasis +>Arts::PlayObject</emphasis +>, et objekt som kan spille en mediatype. Mediaspillere såsom KDE's mediespiller noatun vil kunne afspille hvilket som helst medie som har et PlayObject. Derfor giver det mening at implementere PlayObject for forskellige formater (såsom mp3, mpg video, midi, wav, ...) med dette som grundlag, og der findes allerede mange. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>soundserver.idl</term> + + <listitem +><para +>Her defineres en grænseflade for systemets lydserver artsd. Grænsefladen benævnes <emphasis +>Arts::SoundServer</emphasis +>, og implementerer funktioner såsom at tage imod strømme fra netværket, spille samplinger, oprette andre egne aRts-objekter og så videre. Netværkstransparens er underforstået eftersom MCOP bruges (som for alt øvrigt her). </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsbuilder.idl</term> + <listitem +><para +>Dette modul definerer grundlæggende flowfunktioner, dvs. kombinerer enklere objekter til mere komplekse ved at definere en graf som binder dem sammen. Den definerer den grundlæggende grænseflade <emphasis +>Arts::StructureDesc</emphasis +>, <emphasis +>Arts::ModuleDesc</emphasis +> og <emphasis +>Arts::PortDesc</emphasis +> som indeholder en beskrivelse af en struktur, modul og port. Der er også en måde at oprette et "levende netværk af objekter" fra disse forbindelser og værdibeskrivelserne ved brug af en fabrik. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsmidi.idl</term> + + <listitem +><para +>Dette modulet definerer grundlæggende midi-funktioner, såsom objekter som laver midi-begivenheder, hvad en midi-begivenhed er, og <emphasis +>Arts::MidiManager</emphasis +> til at forbinde producenter og konsumenter af midi-begivenheder, og så videre. Som altid er netværkstransparens underforstået. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsmodules.idl</term> + <listitem +><para +>Her er der diverse yderligere filtre, oscillatorer, lydeffekter, forsinkelser og så videre, alt som behøves for rigtig nyttig signalbehandling, og for at opbygge komplekse instrumenter og effekter fra disse grundlæggende byggeblokke. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>artsgui.idl</term> + + <listitem +><para +>Denne tager sig af synlige objekter. Den definerer den grundlæggende type <emphasis +> Arts::Widget</emphasis +> som alle moduler med en grafisk grænseflade udgår fra. Dette giver uafhængighed af værktøjskasse, og ... visuel redigering af den grafiske grænseflade, og mulighed for at serialisere den grafiske grænseflade. Desuden, eftersom de grafiske komponenter har normale egenskaber, kan deres værdier på en ligetil måde forbindes til visse signalbehandlingsmoduler. (dvs. værdien af en skyder til klipning for et filter). Som altid, netværkstransparent. </para +></listitem> + +</varlistentry> + +</variablelist> +<para +>Hvor det er muligt implementeres aRts selv med IDL. På den anden side er der nogle <emphasis +>sprogspecifikke</emphasis +> programmeringsgrænseflader, som enten bruger enkel C++ eller C. Det er ofte fornuftigt at bruge IDL-grænseflade hvis muligt, og de øvrige grænseflader når det er nødvendigt. Her er en liste over sprogspecifikke programmeringsgrænseflade: </para> + +<variablelist> + +<varlistentry> +<term +>KNotify, KAudioPlayer (indgår i libtdecore)</term> + + <listitem +><para +>Disse er KDE's programmeringsgrænseflader for bekvemmelighed med de enkle og vældigt almindelige tilfælde, hvor man kun vil afspille en sampling. Grænsefladen er enkel C++, Qt/KDE-optimerede, og så enkle som de kan være. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>libartsc</term> + <listitem +><para +>Enkel C-grænseflade for lydserveren. Meget nyttig for at tilrette gamle programmer. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>libmcop</term> + + <listitem +><para +>Her sker al magi som har med MCOP at gøre. Biblioteket indeholder de grundlæggende ting som behøves for at skrive et enkelt MCOP-program, afsenderen, tidtagning, I/O-håndtering, men også de interne funktioner som behøves for at selve MCOP-protokollen skal fungere. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>libartsflow</term> + <listitem +><para +>Foruden implementeringen af artsflow.idl, nogle nyttige værktøjer for konvertering af samplingsrater. </para +></listitem> + +</varlistentry> + +<varlistentry> +<term +>libqiomanager</term> + + <listitem +><para +>Integration af MCOP i Qt's begivenhedsløkke, når man skriver Qt-programmer som bruger MCOP. </para +></listitem> + +</varlistentry> + +</variablelist> + + + +</sect1> +<sect1 id="knotify"> +<title +>knotify</title> +<para +>Endnu ikke skrevet </para> +</sect1> + +<sect1 id="kaudioplayer"> +<title +>kaudioplayer</title> +<para +>Endnu ikke skrevet </para> +</sect1> + +<sect1 id="libkmid"> +<title +>libkmid</title> +<para +>Endnu ikke skrevet </para> +</sect1> + +<sect1 id="kmedia2"> +<title +>kmedia2</title> +<para +>Endnu ikke skrevet </para> +</sect1> + +<sect1 id="soundserver"> +<title +>lydserver</title> +<para +>Endnu ikke skrevet </para> +</sect1> + +<sect1 id="artsflow"> +<title +>artsflow</title> +<para +>Endnu ikke skrevet </para> +</sect1> + +<sect1 id="capi"> +<title +>C <acronym +>API</acronym +></title> + +<sect2 id="capiintro"> +<title +>Indledning</title> + +<para +>C-grænsefladen for &arts; oprettedes for at gøre det let at skrive og overføre enkle C-programmer til &arts; lydserver. Den sørger for strømningsfunktioner (at sende samplingsstrømme til <application +>artsd</application +>), enten med eller uden blokering. For de fleste programmer tager man helt enkelt de få systemkald væk som håndterer lydenheden og skifter dem ud mod passende kald til &arts;.</para> + +<para +>Jeg lavede to overførsler for at verificere idéen: <application +>mpg123</application +> og <application +>quake</application +>. Du kan skaffe programrettelserne <ulink url="http://space.twc.de/~stefan/kde/download/artsc-patches.tar.gz" +>herfra</ulink +>. Bidrag gerne med dine egne programrettelser til vedligeholderen af &arts; eller til programmelpakken for multimedia så de kan integrere understøttelsen for &arts; i deres kode.</para> + +</sect2> + +<sect2 id="capiwalkthru"> +<title +>Hurtig gennemgang</title> + +<para +>At sende lyd til lydserveren med grænsefladen er meget enkelt:</para> +<procedure> +<step +><para +>indsæt deklarationsfilen med <userinput +>#include <artsc.h></userinput +></para +></step> +<step +><para +>initiér grænsefladen med <function +>arts_init()</function +></para +></step> +<step +><para +>opret en strøm med <function +>arts_play_stream()</function +></para +></step> +<step +><para +>indstil særlige parametre med <function +>arts_stream_set()</function +></para +></step> +<step +><para +>skriv samplingsdata til strømmen med <function +>arts_write()</function +></para +></step> +<step +><para +>luk strømmen med <function +>arts_close_stream()</function +></para +></step> +<step +><para +>frigør grænsefladen med <function +>arts_free()</function +></para +></step> +</procedure> + +<para +>Her er et eksempel på et lille program som viser dette:</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 fejl: %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 fejl: %s\n", arts_error_text(errorcode)); + return 1; + } + } + + arts_close_stream(stream); + arts_free(); + + return 0; +} +</programlisting> +</sect2> + +<sect2 id="capiartscconfig"> +<title +>Kompilere og linke: <application +>artsc-config</application +></title> + +<para +>For let at kunne kompilere og linke programmer med &arts; C-grænseflade, findes værktøjet <application +>artsc-config</application +> som kender til hvilke biblioteker som man skal linke med og hvor deklarationsfilerne findes. Det kaldes med</para> + +<screen +><userinput +><command +>artsc-config</command +> <option +>--libs</option +></userinput +> +</screen> + +<para +>for at finde ud af bibliotekerne og </para> + +<screen +><userinput +><command +>artsc-config</command +> <option +>--cflags</option +></userinput +> +</screen> + +<para +>for at finde ud af yderligere C-oversætterflag. Eksemplet ovenfor ville være kunnet kompileres med kommandolinjen:</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 +>Biblioteksreference</title> + +<para +>[HUSK: opret dokumentation for artsc.h med kdoc] </para> + +</sect2> + +</sect1> +</chapter> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/artsbuilder.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/artsbuilder.docbook new file mode 100644 index 00000000000..2e831719cd1 --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/artsbuilder.docbook @@ -0,0 +1,917 @@ +<chapter id="artsbuilder"> +<title +>&arts-builder;</title> + +<sect1 id="overview"> +<title +>Oversigt</title> + +<para +>Først af alt, når du forsøger at køre &arts-builder;, skal du også køre lydserveren (&artsd;). Sædvanligvis, hvis du bruger &kde; 2.1, vil dette allerede være tilfældet. Hvis ikke, så kan du indstille automatisk start af lydserveren i &kcontrol;, med <menuchoice +><guilabel +>Lyd</guilabel +><guilabel +>Lydserver</guilabel +></menuchoice +>. </para> + +<para +>Når du kører &arts;, kører den altid små moduler. &arts-builder; er et værktøj til at oprette nye strukturer af små sammenkoblede moduler. Du klikker helt enkelt indeni gitteret for at tilføje et modul. For at gøre dette, vælges de fra menuen <guimenu +>Moduler</guimenu +>, og der klikkes et sted i den grøngrå plan. </para> + +<para +>Moduler har ofte porte (hvor lydsignaler almindeligtvis ledes ind eller ud). For at koble to porte sammen, klikkes på den første, som gør at den bliver orange, og derefter klikkes på den anden. Du kan kun forbinde en ind-port (på oversiden af et modul) med en ud-port (på undersiden af et modul). Hvis du vil angive en konstant værdi for en port (eller afbryde forbindelsen til den), gøres det ved at dobbeltklikke på porten. </para> + +</sect1> + +<sect1 id="artsbuilder-tutorial"> +<title +>Gennemgang</title> + +<sect2 id="step-1"> +<title +>Trin 1</title> + +<para +>Start &arts-builder;. </para> + +<para +>Du behøver et Synth_AMAN_PLAY-modul for at høre uddata som du laver. Så opret et Synth_AMAN_PLAY-modul ved at vælge <menuchoice +><guimenu +>Moduler</guimenu +> <guisubmenu +>Syntese</guisubmenu +> <guisubmenu +>Lyd-IO</guisubmenu +> <guisubmenu +>Synth_AMAN_PLAY</guisubmenu +></menuchoice +> og klikke på den tomme modulplads. Placér den cirka nedenfor den femte linje, eftersom vi vil tilføje en del ting ovenfor. </para> + +<para +>Modulet vil have en parameter <parameter +>title</parameter +> (porten længst til venstre), og <parameter +>autoRestoreID</parameter +> (ved siden af porten længst til venstre) for at den skal kunne findes. For at udfylde disse her, dobbeltklikkes på portene, der vælges en konstant værdi og skrives <userinput +>gennemgang</userinput +> i redigeringsfeltet. Klik på <guibutton +>O.k.</guibutton +> for at anvende. </para> + +<para +>Vælg <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Kør struktur</guimenuitem +> </menuchoice +>. Du hører absolut ingenting. Afspilningsmodulet har også brug for noget inddata... ;) Hvis du har lyttet til tavsheden et stykke tyd, klik så på <guibutton +>Afslut</guibutton +> og gå til trin 2. </para> +</sect2> + +<sect2 id="step-2"> +<title +>Trin 2</title> + +<para +>Opret en Synth_WAVE_SIN-modul (fra <menuchoice +> <guimenu +>Moduler</guimenu +> <guimenuitem +>Syntese</guimenuitem +> <guimenuitem +>Bølgeformer</guimenuitem +></menuchoice +>) og placér den over Synth_AMAN_PLAY-modulet (lad en linjes mellemrum være mellem dem). </para> + +<para +>Som du ser, så producerer den noget uddata, men kræver <guilabel +>pos</guilabel +> som inddata. Lad os først sende uddata til højtalerne. Klik på porten <guilabel +>out</guilabel +> på Synth_WAVE_SIN og derefter på porten <guilabel +>left</guilabel +> på Synth_AMAN_PLAY. Voila, du har sammenkoblet to moduler. </para> + +<para +>Oscillatorer i &arts; kræver ikke en frekvens som inddata, men i stedet en position på bølgeform. Positionen skal være mellem 0 og 1, som i et standardobjekt Synth_WAVE_SIN oversættes til området 0 .. 2*Pi. For at oprette oscillerende værdier fra en frekvens, bruges et Synth_FREQUENCY modul. </para> + +<para +>Opret en Synth_FREQUENCY-modul (fra <menuchoice +> <guimenu +>Moduler</guimenu +> <guimenuitem +>Syntese</guimenuitem +> <guimenuitem +>Oscillation & modulation</guimenuitem +></menuchoice +>) og forbind dets <quote +>pos</quote +> udgang til <quote +>pos</quote +> indgangen på Synth_WAVE_SIN. Sæt frekvensporten for frekvensgeneratoren til den konstante værdi 440. </para> + + +<para +>Vælg <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Kør struktur</guimenuitem +> </menuchoice +>. Du vil høre en sinusbølge på 440 Hz i en af dine højtalere. Hvis du har lyttet til den et stykke tid, så klik på <guibutton +>O.k.</guibutton +> og gå til trin 3. </para> + +</sect2> + +<sect2 id="step-3"> +<title +>Trin 3</title> + +<para +>O.k., det ville være bedre hvis du kunne høre sinusbølgen i begge højtalerne. Forbind også den højre port på Synth_PLAY til udgangen fra Synth_WAVE_SIN. </para> + +<para +>Opret et Synth_SEQUENCE-objekt (fra <menuchoice +><guimenu +>Moduler</guimenu +> <guisubmenu +>Syntese</guisubmenu +><guisubmenu +>Midi & sekvensering</guisubmenu +></menuchoice +>). Det skal placeres øverst på skærmen. Hvis du behøver mere plads kan du flytte de andre moduler ved at markere dem (for at markere flere moduler holdes shift-tasten nede), og trække dem rundt. </para> + +<para +>Forbind nu frekvensudgangen på Synth_SEQUENCE til frekvensindgangen på Synth_FREQUENCY-modulet. Angiv derefter sekvensens hastighed som konstant værdi 0.13 (hastigheden er porten længst til venstre). </para> + +<para +>Gå nu til porten længst til højre (seq) på Synth_SEQUENCE og skriv <userinput +>A-3;C-4;E-4;C-4;</userinput +> som konstant værdi. Dette angiver en sekvens. Mere om dette i modulreferencen. </para> + +<note> +<para +>Synth_SEQUENCE <emphasis +>behøver</emphasis +> virkelig en sekvens og hastigheden. Uden disse får du måske hukommelsesdump. </para> +</note> + +<para +>Vælg <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Kør struktur</guimenuitem +> </menuchoice +>. Du vil høre en behagelig sekvens spille. Når du har nydt følelsen, så klik på <guibutton +>O.k.</guibutton +> og gå til trin 4. </para> +</sect2> + +<sect2 id="step-4"> +<title +>Trin 4</title> + +<para +>Opret et Synth_PSCALE-modul (fra <menuchoice +><guimenu +>Moduler</guimenu +> <guisubmenu +>Syntese</guisubmenu +> <guisubmenu +>Envelopper</guisubmenu +> </menuchoice +>). Afbryd forbindelsen fra udgangen for sinusbølgen ved at dobbeltklikke på den og vælg <guilabel +>ikke forbundet</guilabel +>. Forbind </para> + +<orderedlist +><listitem> +<para +>Udgangen SIN til indgangen på PSCALE</para> +</listitem> +<listitem> +<para +>PSCALE udgangen til AMAN_PLAY i venstre side</para> +</listitem> +<listitem> +<para +>PSCALE udgangen til AMAN_PLAY i højre side</para> +</listitem> +<listitem> +<para +>SEQUENCE pos til PSCALE pos</para> +</listitem> +</orderedlist> + +<para +>Til slut, sættes PSCALE top til en værdi, for eksempel 0.1. </para> + +<para +>Hvordan virker dette nu: Synth_SEQUENCE giver yderligere information om positionen for tonen den spiller lige nu, hvor 0 betyder netop påbegyndt og 1 betyder afsluttet. Modulet Synth_PSCALE skalerer lydstrømmen som sendes gennem den fra lydstyrke 0 (tavs) til 1 (oprindelig lydstyrke) tilbage til 0 (tavs) ifølge positionen. Positionen hvor toppen skal ske kan angives som top. 0.1 betyder at efter 10 % af tonen er spillet har lydstyrken nået sin maksimale værdi, og begynder derefter at aftage. </para> + + +<para +>Vælg <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Kør struktur</guimenuitem +> </menuchoice +>. Du vil høre en behagelig sekvens spille. Når du har nydt følelsen, klik på <guibutton +>O.k.</guibutton +> og gå til trin 5. </para> + +</sect2> + +<sect2 id="step-5-starting-to-beam-data-around"> +<title +>Trin 5: Begynder at sende data rundt ;)</title> + +<para +>Start endnu en &arts-builder;.</para> + +<para +>Placér en Synth_AMAN_PLAY i den, og indstil den til et rimeligt navn. Placér en Synth_BUS_DOWNLINK i den og:</para> + +<orderedlist> +<listitem> +<para +>Sæt Synth_BUS_DOWNLINK bus til lyd (det er kun et navn, kald den Peter hvis du har lyst) </para> +</listitem> +<listitem> +<para +>Forbind Synth_BUS_DOWNLINK left (venstre) til Synth_AMAN_PLAY left. </para> +</listitem> +<listitem> +<para +>Forbind Synth_BUS_DOWNLINK right (højre) til Synth_AMAN_PLAY right. </para> +</listitem> +</orderedlist> + +<para +>Begynd at køre strukturen. Som ventet hører du ingenting, ... ikke endnu. </para> + +<para +>Gå tilbage til strukturen med Synth_WAVE_SIN tingene og udbyt Synth_AMAN_PLAY-modulet mod en Synth_BUS_UPLINK, og indstil navnet til lyd (eller Peter hvis du vil). At fjerne moduler gøres ved at markere dem og vælge <menuchoice +><guimenu +>Redigér</guimenu +> <guimenuitem +>slet</guimenuitem +></menuchoice +> fra menuen (eller trykke på tasten <keycap +>Del</keycap +>). </para> + +<para +>Vælg <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Kør struktur</guimenuitem +> </menuchoice +>. Du vil høre sekvensen med skalerede toner, transporteret over bussen. </para> + +<para +>Hvis du vil finde ud af hvorfor noget sådant her kan være nyttigt, så klik på <guibutton +>O.k.</guibutton +> (i &arts-builder; som kører Synth_SEQUENCE tingene, du kan lade den anden fortsætte med at køre) og gå til trin 6. </para> +</sect2> + +<sect2 id="step-6-beaming-for-advanced-users"> +<title +>Trin 6: Send data for avancerede brugere</title> + +<para +>Vælg <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Omdøb struktur</guimenuitem +></menuchoice +> fra menuen i den aRts-bygger som indeholder Synth_SEQUENCE tingene, og kald den gennemgang. Tryk på <guibutton +>O.k.</guibutton +>. </para> + +<para +>Vælg <menuchoice +><guimenu +>Fil</guimenu +> <guimenuitem +>Gem</guimenuitem +> </menuchoice +>. </para> + +<para +>Start yderligere en &arts-builder; og vælg <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Åbn</guimenuitem +> </menuchoice +>, og indlæs gennemgangen igen. </para> + +<para +>Nu kan du vælge <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Kør struktur</guimenuitem +> </menuchoice +> i begge &arts-builder;'er som har strukturen. Nu hører du det samme to gange. Afhængig af hvornår du starter dem kommer det til at lyde mere eller mindre godt. </para> + +<para +>En anden ting som det kan være godt at gøre på dette tidspunkt er at starte &noatun;, og spille en <literal role="extension" +>mp3</literal +>-fil. Start derefter &artscontrol;. Gå til <menuchoice +><guimenu +>Vis</guimenu +><guimenuitem +>Vis lydhåndtering</guimenuitem +></menuchoice +>. Det du ser er &noatun; og din struktur <quote +>gennemgang</quote +> afspille noget. Det gode som du kan gøre er: dobbeltklik på &noatun;. Du får nu en liste over tilgængelige busser. Og se? Du kan lade &noatun; sende sin udskrift via lydbussen til afspilningsstrukturen som din gennemgang sørger for. </para> +</sect2> + +<sect2 id="step-7-midi-synthesis"> +<title +>Trin 7: Midisyntese</title> + +<para +>Endelig, nu skal du kunne lave din sinusbølge om til et rigtigt instrument. Dette er kun meningsfuldt hvis du har noget passende som kan sende &MIDI;-begivenheder til &arts;. Her beskriver jeg hvordan du kan bruge et eksternt keyboard, men en sequencer, såsom &brahms;, som kender til midibussen virker også. </para> + +<para +>Først af alt, så ryd op på din desktop indtil du kun har én &arts-builder; med sinusbølgestrukturen i gang (men lad den ikke køre). Gå derefter tre gange til <menuchoice +><guimenu +>Porte</guimenu +> <guisubmenu +>Opret IN-lydsignal</guisubmenu +></menuchoice +>, og tre gange til <menuchoice +><guimenu +>Porte</guimenu +> <guisubmenu +>Opret UT-lydsignal</guisubmenu +></menuchoice +>. Placér portene et sted. </para> + +<para +>Gå til <menuchoice +><guimenu +>Porte</guimenu +> <guilabel +>Ændr positioner og navne</guilabel +></menuchoice +> og døb portene frequency, velocity, pressed, left, right, done. </para> + +<para +>Endelig kan du slette modulet Synth_SEQUENCE, og i stedet forbinde inddataporten frequency for strukturen til frekvensporten på Synth_FREQUENCY. Hmm. Men hvad skal man gøre med pos?</para +> <para +>Denne er ikke tilgængelig, eftersom der ikke er nogen algoritme i værdier som kan forudse hvornår brugeren vil slippe tasten han netop trykkede ned på sit midi-keyboard. Vi har i stedet parameteren pressed, som kun angiver om brugeren stadigvæk holder tasten nede. (pressed = 1: tasten stadigvæk nedtrykt, pressed = 0: tasten sluppet) </para> + +<para +>Dette betyder også at Synth_PSCALE-objektet skal udskiftes nu. Kobl en Synth_ENVELOPE_ADSR ind i stedet (fra <menuchoice +><guimenu +>Moduler</guimenu +> <guisubmenu +>Syntese</guisubmenu +> <guisubmenu +>Envelopper</guisubmenu +> </menuchoice +>). Forbind: </para> + +<orderedlist> +<listitem> +<para +>Strukturen pressed indgang til ADSR active</para> +</listitem> +<listitem> +<para +>SIN udgangen til ADSR indgangen</para> +</listitem> +<listitem> +<para +>ADSR udgangen til den venstre strukturudgang</para> +</listitem +><listitem> +<para +>ADSR udgangen til den højre strukturudgang</para> +</listitem> +</orderedlist> + +<para +>Sæt parametrene attack til 0.1, decay til 0.2, sustain til 0.7, release til 0.1. </para> + +<para +>En ting til som vi skal tænke på er at instrumentstrukturen skal på en eller anden måde vide når den har spillet færdig og så kan ryddes væk, eftersom den ellers aldrig ville stoppe også selvom tasten er sluppet. Heldigvis ved ADSR enveloppen når der ikke er mere at høre, eftersom den alligevel skalerer signalet ned til nul på et tidspunkt efter tasten er sluppet. </para> + +<para +>Dette angives ved at sætte udgangen done til 1. Så forbind denne til strukturens udgang. Strukturen fjernes så snart done bliver 1. </para> + +<para +>Omdøb din struktur til instrument_gennemgang (fra <menuchoice +><guimenu +> Fil</guimenu +> <guimenuitem +>Omdøb struktur</guimenuitem +></menuchoice +>. Gem den derefter med Gem som (det standardnavn som nu angives skal være instrument_gennemgang).</para +><para +>Start artscontrol, og gå til <menuchoice +><guimenu +>Vis</guimenu +><guimenuitem +>Vis midihåndtering</guimenuitem +></menuchoice +>, og vælg <menuchoice +><guimenu +>Tilføj</guimenu +><guimenuitem +>aRts syntese midi uddata</guimenuitem +></menuchoice +>. Tilsidst skal du kunne vælge dit instrument (gennemgang) her. </para> + +<para +>Åbn en terminal og skriv <userinput +><command +>midisend</command +></userinput +>. Du vil se at <command +>midisend</command +> og instrumentet nu er på listen i &arts; &MIDI;-håndtering. Efter at have valgt begge to og trykket på <guibutton +>forbind</guibutton +>, er vi til sidst klare. Tag dit keyboard og begynd at spille (det skal naturligvis være forbundet til din maskine). </para> +</sect2> + +<sect2 id="suggestions"> +<title +>Forslag</title> + +<para +>Du bør nu kunne arbejde med &arts;. Her er nogle vink om hvad du nu vil kunne gøre for at forbedre dine strukturer: </para> + +<itemizedlist> +<listitem> +<para +>Forsøg at bruge noget andet end en sinusbølge. Hvis du kobler en trekantbølge ind, TRI, synes du formodentlig ikke at lyden er særligt behagelig, Men forsøg at tilføje et SHELVE_CUTOFF-filter direkte efter trekantbølgen for at klippe frekvenserne ovenfor ved en vis frekvens (forsøg med noget i retning af 1000 Hz, eller endnu bedre to gange inddatafrekvensen eller inddatafrekvensen + 2000 Hz eller noget sådant). </para> +</listitem> +<listitem> +<para +>Forsøg at bruge mere end en oscillator. Synth_XFADE kan bruges til at overtone (blande) to signaler, Synth_ADD til at addere dem. </para> +</listitem> +<listitem> +<para +>Forsøg at sætte frekvenserne for oscillatorerne til nogle forskellige værdier, det giver behagelige oscillationer. </para> +</listitem> +<listitem> +<para +>Eksperimentér med mere end en envelope. </para> +</listitem> +<listitem> +<para +>Forsøg at syntetisere instrumenter med forskellig lyd til venstre og højre. </para> +</listitem> +<listitem> +<para +>Forsøg at efterbehandle signalet når det kommer ud fra bussens nedlink. Du kunne for eksempel blande en forsinket version af signalet med originalen for at få en ekkoeffekt. </para> +</listitem> +<listitem> +<para +>Forsøg at bruge anslagsstyrken, velocity (dette er styrken som tasten er trykket ned med, man kan også kalde det lydstyrken). Specialeffekter opstår altid hvis dette ikke kun ændrer lydstyrken på signalerne som laves, men også instrumentets lyd (for eksempel klipningsfrekvensen). </para> +</listitem> +<listitem> +<para +>...</para> +</listitem> +</itemizedlist> + +<para +>Hvis du har lavet noget storartet, så overvej gerne at give det til &arts;' netside, eller til at indgå i næste udgave. </para> +</sect2> + +</sect1> + +<sect1 id="artsbuilder-examples"> +<title +>Eksempel</title> + +<para +>&arts-builder; levereres med flere eksempler, som kan åbnes med <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Åbn eksempel...</guimenuitem +> </menuchoice +>. Nogle af dem er i mappen, mens nogen (som af en eller anden grund ikke virker med den nuværende udgave) er efterladt i todo-mappen. </para> +<para +>Eksemplerne kan inddeles i flere kategorier: </para> + +<itemizedlist> +<listitem> +<para +>Selvstændige eksempler som illustrerer hvordan hvert af de indbyggede aRts-moduler bruges (som hedder <filename +>example_*.arts</filename +>). Disse sender typisk noget uddata til et lydkort. </para> +</listitem> + +<listitem> +<para +>Instrumenter som bygges fra aRts-moduler på lavere niveau (som hedder <filename +>instrument_*.arts</filename +>). Disse følger en standardkonvention for ind- og udporte så de kan bruges af &MIDI;-håndteringen i &artscontrol;. </para> +</listitem> + +<listitem> +<para +>Skabeloner til at oprette nye moduler (som hedder <filename +>template_*.arts</filename +>). </para> +</listitem> + +<listitem> +<para +>Effekter som kan bruges som genbrugelige byggeblokke (som hedder <filename +>effect_*.arts</filename +>) [ alle i todo ] </para> +</listitem> + +<listitem> +<para +>Mikserelementer som bruges til at oprette miksere, inklusive grafiske styremoduler (som hedder <filename +>mixer_element_*.arts</filename +>). [ alle i todo ] </para> +</listitem> + +<listitem> +<para +>Diverse moduler som ikke passer ind i nogen af de ovenstående kategorier. </para> +</listitem> +</itemizedlist> + +<variablelist> +<title +>Detaljeret beskrivelse af hvert modul:</title> +<varlistentry> +<term +><filename +>example_stereo_beep.arts</filename +></term> +<listitem> +<para +>Laver en 440 Hz sinusbølge i venstre kanal og en 880 Hz sinusbølge i højre kanal, og sender dem til lydkortet. Denne henvises til i &arts; dokumentation. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_sine.arts</filename +></term> +<listitem> +<para +>Laver en 440 Hz sinusbølge. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_pulse.arts</filename +></term> +<listitem> +<para +>Laver en 440 Hz pulsbølge med 20% aktivitet. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_softsaw.arts</filename +></term> +<listitem> +<para +>Laver en 440 Hz savtandsbølge. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_square.arts</filename +></term> +<listitem> +<para +>Laver en 440 Hz firkantbølge. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_tri.arts</filename +></term> +<listitem> +<para +>Laver en 440 Hz trekantbølge. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_noise.arts</filename +></term> +<listitem> +<para +>Laver hvid støj. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_dtmf1.arts</filename +></term> +<listitem> +<para +>Laver en dualtone ved at producere sinusbølger med 697 og 1209 Hz, skalere dem til 0,5 og addere dem. Dette er DTMF-tonen for cifferet "1" på en trykknaptelefon. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_atan_saturate.arts</filename +></term> +<listitem> +<para +>Kører en trekantbølge gennem et atan-mætningsfilter. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_autopanner.arts</filename +></term> +<listitem> +<para +>Bruger autopanorering til at panorere en 400 Hz sinusbølge mellem venstre og højre højtaler med en hastighed på 2 Hz. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_brickwall.arts</filename +></term> +<listitem> +<para +>Skalerer en sinusbølge med en faktor 5 og kører den derefter gennem ved en murstensvægsbegrænser. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_bus.arts</filename +></term> +<listitem> +<para +>Linker ned fra en bus som hedder <quote +>Bus</quote +> og linker op til bussen <quote +>out_soundcard</quote +> med venstre og højre kanal byttet om. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_cdelay.arts</filename +></term> +<listitem> +<para +>Linker ned fra en bus som hedder <quote +>Delay</quote +> og linker højre kanal op gennem en 0,5 sekunders forsinkelse, og venstre kanal uforandret. Du kan bruge &artscontrol; til at forbinde effekten til lydafspilning og observere resultatet. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_delay.arts</filename +></term> +<listitem> +<para +>Dette er det samme som <filename +>example_cdelay.arts</filename +> men bruger forsinkelseseffekten. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_capture_wav.arts</filename +></term> +<listitem> +<para +>Dette bruger Synth_CAPTURE_WAV til at gemme en 400 Hz sinusbølge som en wav-fil. Kør modulet i nogle sekunder, og kig derefter på filen som blev lavet i <filename class="directory" +>/tmp</filename +>. Du kan afspille filen med en mediaspiller såsom <application +>kaiman</application +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_data.arts</filename +></term> +<listitem> +<para +>Dette bruger Data-modulet til at oprette en konstant strøm af værdien <quote +>3</quote +> og sender den til et Debug-modul for at vise det periodisk. Det indeholder også et Nil-modul, og viser hvordan den kan bruges til ikke at gøre noget overhovedet. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_adsr.arts</filename +></term> +<listitem> +<para +>Viser hvordan en enkelt instrumentlyd kan laves med envelope ADSR-modulet, som udløses repetitivt af en firkantbølge. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_fm.arts</filename +></term> +<listitem> +<para +>Dette bruger FM Source-modulet til at lave en 440 Hz sinusbølge som frekvensmoduleres med en 5 Hz hastighed. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_freeverb.arts</filename +></term> +<listitem> +<para +>Dette forbinder Freeverb-effekten fra et busnedlink til et busoplink. Du kan bruge artscontrol til at forbinde effekten til lydafspilning og observere resultatet. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_flanger.arts</filename +></term> +<listitem> +<para +>Dette implementerer en enkel flangereffekt (det synes dog ikke at virke endnu). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_moog.arts</filename +></term> +<listitem> +<para +>Denne struktur kombinerer de to kanaler fra en bus ind i en, sender den gennem et Moog VCF filter, og sender den derefter til bussen out_soundcard. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_pitch_shift.arts</filename +></term> +<listitem> +<para +>Denne struktur sender venstrekanalens lyddata gennem en tonehøjdeændringseffekt. Justér hastighedsparameteren for at variere effekten. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_rc.arts</filename +></term> +<listitem> +<para +>Denne struktur sender hvid støj gennem et RC-filer og ud til lydkortet. Ved at kigge på FFT måleren i artscontrol kan du se hvordan dette adskiller sig fra en ufiltreret støjbølgeform. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_sequence.arts</filename +></term> +<listitem> +<para +>Dette demonstrerer Sequence-modulet ved at spille en sekvens af toner. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_shelve_cutoff.arts</filename +></term> +<listitem> +<para +>Denne struktur sender hvid støj gennem et klippefilter og ud til lydkortet. Ved at kigge på FFT måleren i artscontrol kan du se hvordan dette adskiller sig fra en ufiltreret støjbølgeform. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_equalizer.arts</filename +></term> +<listitem> +<para +>Dette demonstrerer modulet Std_Equalizer. Det forstærker de lave og høje frekvenser med 6 dB. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_tremolo.arts</filename +></term> +<listitem> +<para +>Dette demonstrerer tremoloeffekten. Det modulerer venstre og højre kanal med en 10 Hz tremolo. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_xfade.arts</filename +></term> +<listitem> +<para +>Dette eksempel blander 440 og 880 Hz sinusbølger med en overtoning. Justér værdien på overtoningens procentindgang fra -1 til 1 for at kontrollere blandningen af de to signaler. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_pscale.arts</filename +></term> +<listitem> +<para +>Dette illustrerer Pscale-modulet (jeg er ikke sikker på at det er et meningsfuldt eksempel). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><filename +>example_play_wav.arts</filename +></term> +<listitem> +<para +>Dette illustrerer modulet Play Wave. Du skal angive hele søgestien til en <literal role="extension" +>.wav</literal +>-fil som filnavneparameter. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>example_multi_add.arts</term> +<listitem> +<para +>Dette viser modulet Multi Add, som accepterer et hvilket som helst antal indgange. Det opsummerer tre Data-moduler som producerer inddata 1, 2 og 3, og viser resultatet 6. </para> +</listitem> +</varlistentry> +</variablelist> + +</sect1> +</chapter> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/detail.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/detail.docbook new file mode 100644 index 00000000000..7faa7718db4 --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/detail.docbook @@ -0,0 +1,1383 @@ +<!-- <?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-in-detail"> +<title +>&arts; i detalje</title> + +<sect1 id="architecture"> +<title +>Arkitektur</title> + +<mediaobject> +<imageobject> +<imagedata fileref="arts-structure.png" format="PNG"/> +</imageobject> +<textobject +><phrase +>&arts;-strukturer.</phrase +></textobject> +</mediaobject> +</sect1> + +<sect1 id="modules-ports"> +<title +>Moduler & porte</title> + +<para +>Idéen med &arts; er at syntese kan gøres med små moduler, som kun gør en eneste ting, og derefter kombinere dem i komplekse strukturer. De små moduler har normalt indgange, hvor de kan modtage nogle signaler eller parametre, og udgange hvor de producerer nogle signaler. </para> + +<para +>Et modul (Synth_ADD) tager for eksempel kun de to signaler på sine indgange og lægger dem sammen. Resultatet er tilgængeligt som et uddatasignal. De steder hvor moduler sørger for deres ind- eller udsignaler kaldes porte. </para> + +</sect1> + +<sect1 id="structures"> +<title +>Strukturer</title> + +<para +>En struktur er en kombination af sammenkoblede moduler, hvor nogen kan have parametre som er kodet direkte på deres inddataporte, andre kan være sammenkoblede, og en del kan være slet ikke forbundet. </para> + +<para +>Det du kan gøre med &arts-builder; er at beskrive strukturer. Du beskriver hvilke moduler du vil skal kobles sammen med hvilke andre moduler. Når du er klar, kan du gemme strukturbeskrivelsen i en fil, eller bede &arts; om at oprette (køre) den struktur som du har beskrevet. </para> + +<para +>Derefter hører du formodlig noget lyd, hvis du har gjort alt på den rigtige måde. </para> +</sect1> + +<!-- TODO + +<sect1 id="streams"> +<title +>Streams</title> + +</sect1> + +--> + +<sect1 id="latency"> +<title +>Latens</title> + +<sect2 id="what-islatency"> +<title +>Hvad er latens?</title> + +<para +>Antag at du har et program som hedder <quote +>musepling</quote +> (som skal afgive en <quote +>pling</quote +>-lyd hvis du klikker på en museknap). Latensen er tiden mellem din finger trykker på museknappen til du hører plinget. Latensen for dette scenario består af flere forskellige latenstider, som har forskellige årsager. </para> + +</sect2> + +<sect2 id="latenbcy-simple"> +<title +>Latens i enkle programmer</title> + +<para +>I dette enkle program opstår latensen på følgende steder: </para> + +<itemizedlist> + +<listitem> +<para +>Tiden til kernen har meddelt X11-serveren at museknappen er trykket ned. </para> +</listitem> + +<listitem> +<para +>Tiden til X11-serveren har meddelt dit program at museknappen er trykket ned. </para> +</listitem> + +<listitem> +<para +>Tiden til musepling-programmet har bestemt at denne knap var værd at få et pling afspillet. </para> +</listitem> + +<listitem> +<para +>Tiden det tager for musepling-programmet at fortælle lydserveren at den skal afspille et pling. </para> +</listitem> + +<listitem> +<para +>Tiden det tager for plinget (som lydserveren begynder at mikse med øvrig uddata med det samme) at gå gennem bufferet data, til det virkelig når stedet hvor lydkortet spiller. </para> +</listitem> + +<listitem> +<para +>Tiden det tager for pling-lyden at gå fra højtalerne til dine ører. </para> +</listitem> +</itemizedlist> + +<para +>De første tre punkter er latensen udenfor &arts;. De er interessante, men udenfor dette dokuments rækkevidde. Ikke desto mindre skal du vide at de findes, så selvom du har optimeret alt andet til virkelig små værdier, så får du måske ikke nødvendigvis nøjagtigt det resultat du forventer dig. </para> + +<para +>At bede serveren om at spille noget indebærer oftest kun et enkelt &MCOP;-kald. Der er målinger som bekræfter at det kan lade sig gøre at bede serveren at spille noget 9000 gange pr sekund med den nuværende implementering, på samme værtsmaskine med Unix domæne-sokler. Jeg antager at det meste af dette er kernens omkostning, for at skifte fra en proces til en anden. Naturligvis ændres denne værdi med den nøjagtige type af parametrene. Hvis man overfører et helt billede med et kald, bliver det langsommere end hvis man kun overfører en "long" værdi. Det samme er sandt for returværdien. For almindelige strenge (som filnavnet på <literal role="extension" +>wav</literal +>-filen som skal afspilles) skulle dette ikke være et problem. </para> + +<para +>Dette betyder at vi kan tilnærme denne tid med 1/9000 sekund, det vil sige under 0,15 ms. Vi vil se at dette ikke er relevant. </para> + +<para +>Derefter kommer tiden efter serveren begynder at spille og lydkortet tager imod noget. Serveren skal buffre data, så ingen pauser høres når andre programmer, såsom din X11-server eller <quote +>musepling</quote +>-programmet, kører. Den måde dette håndteres på &Linux; er at der er et antal fragmenter af en vis størrelse. Serveren genopfylder fragmenter, og lydkortet afspiller fragmenter. </para> + +<para +>Så antag at der er tre fragmenter. Serveren genopfylder det første og lydkortet begynder at afspille det. Serveren genopfylder det andet. Serveren genopfylder det tredje. Serveren er klar og andre programmer kan nu gøre noget. </para> + +<para +>Når lydkortet har afspillet det første fragment, begynder det at afspille det andet og serveren begynder at genopfylde det første, og så videre. </para> + +<para +>Den maksimale latenstiden du får med alt dette er (antal fragmenter) * (størrelse på hvert fragment) / (samplingsfrekvens * (størrelse på hver sampling)). Hvis vi antager 44 kHz stereo, og syv fragmenter på 1024 byte (de nuværende standardindstillinger i aRts), så får vi 40 ms. </para> + +<para +>Disse værdier kan indstilles efter dine behov. <acronym +>CPU</acronym +>-brugen øges dog med mindre latenstider, eftersom lydserveren skal genopfylde bufferne oftere, og med mindre dele. Det er også oftest umuligt at nå bedre værdier uden at give lydserveren realtidsprioritet, eftersom man ellers ofte får pauser. </para> + +<para +>Det er imidlertid realistisk at lave noget i stil med 3 fragmenter med 256 byte hver, som ville ændre denne værdi til 4,4 ms. Med 4,4 ms forsinkelse ville &arts; <acronym +>CPU</acronym +>-forbrug være cirka 7,5 %. Med en 40 ms forsinkelse, ville den være cirka 3 % (for en PII-350, og værdien kan afhænge af dit lydkort, version af kernen og andet). </para> + +<para +>Så er der tiden som det tager for pling-lyden at gå fra højtalerne til dine ører. Antag at din afstand fra højtalerne er 2 meter. Lyden bevæger sig med hastigheden 330 meter pr sekund. Så vi kan ansætte denne tid til 6 ms. </para> + +</sect2> + +<sect2 id="latency-streaming"> +<title +>Latenstid i programmer med lydstrømme</title> + +<para +>Programmer med lydstrømme er dem som laver deres lyd selv. Tænk dig til et spil som sender en konstant strøm med samplinger, og nu skal tilpasses til at afspille lyd via &arts;. Som et eksempel: når jeg trykker på en tast så hopper figuren som jeg bruger, og en bang-lyd afspilles. </para> + +<para +>Først så skal du vide hvordan &arts; håndterer strømme. Det er meget lignende I/O med lydkortet. Spillet sender nogle pakker med samplinger til lydserveren, lad os antage tre styk. Så snart lydserveren er klar med den første pakke, sender den en bekræftelse tilbage til spillet om at denne pakke er færdig. </para> + +<para +>Spillet laver yderligere en lydpakke og sender den til serveren. I mellemtiden begynder serveren at konsumere den anden lydpakke, og så videre. Latenstiderne ligner dem i det enklere tilfælde: </para> + +<itemizedlist> +<listitem> +<para +>Tiden til kernen har meddelt X11-serveren at en knap er trykket ned. </para> +</listitem> + +<listitem> +<para +>Tiden til X11-serveren har meddelt spillet at en knap er trykket ned. </para> +</listitem> + +<listitem> +<para +>Tiden til spillet har bestemt at denne knap var værd at få et bang afspillet. </para> +</listitem> + +<listitem> +<para +>Tiden til lydpakken som afspilles er begyndt at putte bang-lyden ind når lydserveren. </para> +</listitem> + +<listitem> +<para +>Tiden det tager for banget (som lydserveren begynder at mikse med øvrig uddata med det samme) at gå gennem bufferdata, til det virkelig når stedet hvor lydkortet spiller. </para> +</listitem> + +<listitem> +<para +>Tiden det tager for bang-lyden fra højtalerne at nå dine ører. </para> +</listitem> + +</itemizedlist> + +<para +>De eksterne latenstider er, som ovenfor, udenfor dette dokuments rækkevidde. </para> + +<para +>Det er åbenbart at latenstiden for strømme afhænger af tiden det tager for alle pakker som bruges at afspilles en gang. Så den er (antal pakker) * (størrelse på hver pakke) / (samplingsfrekvensen * (størrelse på hver sampling)). </para> + +<para +>Som du ser er dette samme formel som gælder for fragmenterne. For spil er der dog ingen grund til at have så korte forsinkelser som ovenfor. Jeg vil sige at et realistisk eksempel for et spil kunne være 2048 byte pr pakke, når der bruges 3 pakker. Latenstidsresultatet ville så være 35 ms. </para> + +<para +>Dette er baseret på følgende: antag at et spil viser 25 billeder pr sekund (for skærmen). Det er antageligt helt sikkert at antage at en forskel på et billede for lydudskriften ikke vil kunne mærkes. Derfor er 1/25 sekunds forsinkelse for lydstrømmen acceptabelt, hvilket på sin side betyder at 40 ms skulle være o.k. </para> + +<para +>De fleste personer kører heller ikke deres spil med realtidsprioritet, og faren for pauser i lyden kan ikke negligeres. Strømme med 3 pakker på 256 byte er mulige (jeg prøvede det) - men forårsager meget <acronym +>CPU</acronym +>-forbrug til strømning. </para> + +<para +>Latenstider på serversiden kan du beregne præcis som ovenfor. </para> + +</sect2> + +<sect2 id="cpu-usage"> +<title +>Nogle <acronym +>CPU</acronym +>-forbrugshensyn</title> + +<para +>Der er mange faktorer som påvirker <acronym +>CPU</acronym +>-forbrug i et komplekst scenario, med nogle programmer med lydstrømme og nogle andre programmer, nogle plugin i serveren, osv. For at angive nogle få: </para> + +<itemizedlist> +<listitem> +<para +>Rå <acronym +>CPU</acronym +>-forbrug for de nødvendige beregninger. </para> +</listitem> + +<listitem> +<para +>&arts; interne skemalægningsomkostning - hvordan &arts; bestemmer hvornår hvilket modul skal beregne hvad. </para> +</listitem> + +<listitem> +<para +>Omkostning til konvertering af heltal til decimaltal. </para> +</listitem> + +<listitem> +<para +>&MCOP; protokolomkostning. </para> +</listitem> + +<listitem> +<para +>Kernens proces/sammenhængsskift. </para> +</listitem> + +<listitem> +<para +>Kernens kommunikationsomkostning. </para> +</listitem> +</itemizedlist> + +<para +>For beregning af rå <acronym +>CPU</acronym +>-forbrug, hvis du afspiller to strømme samtidigt skal du gøre additioner. Hvis du anvender et filter, er visse beregninger indblandede. For at tage et forenklet eksempel, at addere to strømme kræver måske fire <acronym +>CPU</acronym +>-cykler pr addition, på en 350 MHz processor er dette 44100 * 2 * 4 / 350000000 = 0,1 % <acronym +>CPU</acronym +>-forbrug. </para> + +<para +>&arts; interne skemalægning: &arts; skal bestemme hvilket plugin som skal beregne hvad hvornår. Dette tager tid. Brug et profileringsværktøj hvis du er interesseret i det. Hvad som kan siges i almindelighed er at jo mindre realtid som bruges (dvs. jo større blokke som kan beregnes af gangen) desto mindre skemalægningsomkostning fås. Udover beregning af blokke med 128 samplinger af gangen (altså med brug af fragmentstørrelser på 512 byte) er skemalægningsomkostningen formodentlig ikke værd at bryde sig om. </para> + +<para +>Konvertering fra heltal til decimaltal: &arts; bruger decimaltal som internt dataformat. De er enkle at håndtere, og på moderne processorer er de ikke meget langsommere end heltalsoperationer. Hvis der er klienter som afspiller data som ikke er decimaltal (såsom et spil som skal lave sin lydudskrift via &arts;), behøves konvertering. Det samme gælder hvis du vil afspille lyd på dit lydkort. Lydkortet behøver heltal, så du skal konvertere. </para> + +<para +>Her er værdier for en Celeron, cirka klokcykler pr sampling, med -O2 og egcs 2.91.66 (målt af Eugene Smith <email +>hamster@null.ru</email +>). Dette er naturligvis yderst processorafhængigt: </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 +>Så dette betyder 1 % <acronym +>CPU</acronym +>-forbrug for konvertering og 5 % for interpolation på denne 350 MHz processor. </para> + +<para +>&MCOP; protokollomkostning: &MCOP; klarer, som en tommelfingerregel, 9000 kald pr sekund. En stor del af dette er ikke &MCOP;'s fejl, men hører sammen med de to grunde for kernen som nævnes nedenfor. Dette giver i alle tilfælde en basis for at udføre beregninger af hvad omkostningen er for strømning. </para> + +<para +>Hver datapakke som sendes med en strøm kan anses for at være et &MCOP;-kald. Store pakker er naturligvis langsommere end 9000 pakker/s, men det giver en god idé. </para> + +<para +>Antag at du bruger pakkestørrelser på 1024 byte. På denne måde, for at overføre en strøm med 44 kHz stereo, behøver du at overføre 44100 * 4 / 1024 = 172 pakker pr sekund. Antag at du kunne overføre 9000 pakker med 100 % CPU-forbrug, så får du (172 *100) / 9000 = 2 % <acronym +>CPU</acronym +>-forbrug på grund af strømningen med 1024 byte pakker. </para> + +<para +>Dette er en approksimation. Det viser i alle tilfælde at du ville klare dig meget bedre (hvis du har råd for latenstiden), med for eksempel at bruge pakker på 4096 byte. Her kan vi oprette en kompakt formel, ved at beregne pakkestørrelsen som forårsager 100 % <acronym +>CPU</acronym +>-forbrug som 44100 * 4 / 9000 = 19,6 samplinger, og på den måde få hurtigformlen: </para> + +<para +><acronym +>CPU</acronym +>-forbrug for en strøm i procent = 1960 / (din pakkestørrelse) </para> + +<para +>som giver os 0,5 % <acronym +>CPU</acronym +>-forbrug med en strøm af 4096 byte pakker. </para> + +<para +>Kernens proces/sammenhængsskift: Dette er en del af &MCOP;-protokollens omkostning. At skifte mellem to processer tager tid. Der er en ny hukommelsesafbildning, cacher er ugyldige, og en del andet (hvis en ekspert på kernen læser dette - fortæl mig om de nøjagtige grunde). Dette betyder: det tager tid. </para> + +<para +>Jeg er ikke sikker på hvor mange procesbyte &Linux; kan lave pr sekund, men værdien er ikke uendelig. Så af &MCOP;-protokollens omkostning, antager jeg at en hel del afhænger af processkift. &MCOP; først påbegyndtes prøvede jeg samme kommunikation inde i en proces, og det var meget hurtigere (cirka fire gange hurtigere). </para> + +<para +>Kernens kommunikationsomkostning: Dette er en del af &MCOP;-protokollens omkostning. At overføre data mellem processer gøres for øjeblikket via et udtag (sokkel). Dette er bekvemt, eftersom den almindelige select() metode kan bruges til at afgøre hvornår en meddelelse er ankommet. Det kan også kombineres med andre I/O-kilder såsom lyd-I/O, X11-server eller hvad som helst andet. </para> + +<para +>Disse læse- og skrivekald koster definitivt processorcykler. For små kald (som at overføre en midi-begivenhed) er det formodentlig ikke så farligt, men for store kald (som at overføre et videobillede på flere Mbyte) er det helt klart et problem. </para> + +<para +>At tilføje brug af delt hukommelse til &MCOP; hvor det er passende er formodentlig den bedste løsning. Det skal dog gøres transparent for anvendelsesprogrammerne. </para> + +<para +>Tag et profileringsværktøj og udfør andre test for at finde ud af nøjagtigt hvordan nuværende lydstrømme påvirkes af ikke at bruge delt hukommelse. Det er dog ikke så dårligt, eftersom lydstrømme (afspilning af mp3) kan gøres med totalt 6 % <acronym +>CPU</acronym +>-forbrug for &artsd; og <application +>artscat</application +> (og 5 % for mp3-afkoderen). Dette omfatter alting fra nødvendige beregninger til omkostning for udtaget, så jeg vil bedømme at man måske ville vinde cirka 1 % på at bruge delt hukommelse. </para> + +</sect2> + +<sect2 id="hard-numbers"> +<title +>Nogle hårde værdier</title> + +<para +>Disse er lavet med den nuværende udviklingsversion. Jeg ville også forsøge med rigtigt svære tilfælde, så dette er ikke hvad programmer til daglig brug ville gøre. </para> + +<para +>Jeg skrev et program som hedder streamsound som sender datastrømmen til &arts;. Her køres det med realtidsprioritet (uden problemer), og et lille plugin på serversiden (lydstyrkeskalning og klipning): </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 +>Hvert af programmerne sender en strøm med 3 fragmenter på 1024 byte (18 ms). Der er tre sådanne klienter som kører samtidigt. Jeg ved at det synes at være lidt vel meget, men som jeg sagde: tag et profileringsværktøj og find ud af hvad som koster tid, og hvis du vil, forbedr det. </para> + +<para +>Jeg tror i alt fald ikke at bruge strømning sådan her er realistisk eller giver mening. For at gøre det hele endnu mere ekstremt, forsøgte jeg med den mindst mulige latenstid. Resultat: man kan bruge strømme uden afbrud med et klientprogram, hvis man tager 2 fragmenter med 128 byte mellem aRts og lydkortet, og mellem klientprogrammet og aRts. Dette betyder at man har en total maksimal latenstid på 128 * 4 / 44100 * 4 = 3 ms, hvor 1,5 ms genereres på grund af I/O til lydkortet og 1,5 ms genereres af kommunikation med &arts;. Begge programmer skal køre med realtidsprioritet. </para> + +<para +>Men dette koster en enorm mængde <acronym +>CPU</acronym +>. Dette eksempel koster cirka 45 % på min P-II/350. Det begynder også at klikke hvis man starter top, flytter vinduer på X11-skærmen eller laver disk-I/O. Alt dette har med kernen at gøre. Problemet er at skemalægge to eller flere processer med realtidsprioritet også koster en enorm anstrengelse, endnu mere end kommunikation og meddelelse til hinanden, &etc;. </para> + +<para +>Tilsidst, et mere hverdagsagtigt eksempel: Dette er &arts; med artsd og en artscat (en klient med datastrøm) som kører 16 fragmenter på 4096 byte: </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> + +</sect1> + +--> + +<sect1 id="busses"> +<title +>Busser</title> + +<para +>Busser er forbindelser som bygges dynamisk for at overføre lyd. Der er et antal oplink og nedlink. Alle signaler fra oplinkene adderes og sendes til nedlinkene. </para> + +<para +>Busser er for øjeblikket implementerede til at virke med stereo, så du kan kun overføre stereodata via busser. Hvis du vil have monodata, ja, overfør det kun på en kanal og sæt den anden til nul eller noget vilkårligt. Hvad du skal gøre er at oprette en eller flere Synth_BUS_UPLINK-objekter og give dem et busnavn, som de skal tale med (f.eks. <quote +>lyd</quote +> eller <quote +>trommer</quote +>). Send derefter helt enkelt data derind. </para> + +<para +>Derefter skal du oprette et eller flere Synth_BUS_DOWNLINK-objekter, og fortælle dem om busnavnet (<quote +>lyd</quote +> eller <quote +>trommer</quote +>... hvis det passer sammen, kommer data igennem), og den blandede lyd kommer ud igen. </para> + +<para +>Oplinkene og nedlinkene kan være i forskellige strukturer, du kan til og med have forskellige aRts-byggere som kører og starte et oplink i en og tage imod data i den anden med et nedlink. </para> + +<para +>Det der er rart ved busser er at de er fuldstændigt dynamiske. Klienter kan kobles ind eller ud i farten. Det skal ikke kunne høres noget klik eller støj når dette sker. </para> + +<para +>Du skal naturligvis ikke tilkoble eller frakoble en klient mens den spiller et signal, eftersom den formodentlig ikke er nul når den kobles ud, og der så opstår et klik. </para> +</sect1> + +<!-- TODO +<sect1 id="network-ransparency"> +<title +>Network Transparency</title> + +</sect1> + +<sect1 id="security"> +<title +>Security</title> + +</sect1> + + +<sect1 id="effects"> +<title +>Effects and Effect Stacks</title> + +</sect1> + +--> +<sect1 id="trader"> +<title +>Handleren</title> + +<para +>&arts;/&MCOP; afhænger helt af at opdele objekter i små komponenter. Dette gør alt meget fleksibelt, eftersom man let kan udvide systemet ved at tilføje nye komponenter, som implementerer nye effekter, filformater, oscillatorer, grafiske elementer, ... Eftersom næsten alt er komponenter, kan næsten alt let udvides uden at ændre eksisterende kildekode. Nye komponenter kan enkelt indlæses dynamisk for at forbedre programmer som allerede eksisterer. </para> + +<para +>For at dette skal virke, kræves der dog to ting: </para> + +<itemizedlist> + +<listitem> +<para +>Komponenter skal fortælle at de findes - de skal beskrive hvilke storartede ting de tilbyder, så programmerne kan bruge dem. </para> +</listitem> + +<listitem> +<para +>Programmer skal aktivt lede efter komponenter som de ville kunne bruge, i stedet for altid at bruge samme komponenter til en vis opgave. </para> +</listitem> + +</itemizedlist> + +<para +>Kombinationen af dette: komponenter som siger <quote +>her er jeg, jeg er smart, brug mig</quote +>, og programmer (eller om man vil, andre komponenter) som går ud og leder efter hvilken komponenter de kan bruge for at få noget gjort, kaldes at handle. </para> + +<para +>I &arts; beskriver komponenter sig selv ved at angive værdier som de <quote +>understøtter</quote +> som egenskaber. En typisk egenskab for en filindlæsningkomponent kan være filendelsen for filerne som den kan behandle. Typiske værdier kan være <literal role="extension" +>wav</literal +>, <literal role="extension" +>aiff</literal +> eller <literal role="extension" +>mp3</literal +>. </para> + +<para +>I virkeligheden kan hver komponent vælge at tilbyde mange forskellige værdier for en egenskab. Så en enkelt komponent ville kunne tilbyde at læse både <literal role="extension" +>wav</literal +> og <literal role="extension" +>aiff</literal +>-filer, ved at angive at den understøtter disse værdier for egenskaben <quote +>Endelse</quote +>. </para> + +<para +>For at gøre dette, skal en komponent placere en <literal role="extension" +>.mcopclass</literal +>-fil som indeholder egenskaberne den understøtter på et passende sted. For vort eksempel, kan den se sådan her ud (og ville være installeret i <filename +><replaceable +>komponentmappen</replaceable +>/Arts/WavPlayObject.mcopclass</filename +>): </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 +>Det er vigtigt at filnavnet på <literal role="extension" +>.mcopclass</literal +>-filen også angiver hvad komponentens grænseflade hedder. Handleren kigger ikke på indholdet overhovedet, hvis filen (som her) hedder <filename +>Arts/WavPlayObject.mcopclass</filename +>, og komponentgrænsefladen hedder <interfacename +>Arts::WavPlayObject</interfacename +> (moduler hører sammen med mapper). </para> + +<para +>For at lede efter komponenter er der to grænseflader (som er definerede i <filename +>core.idl</filename +>, så de er tilgængelige i hvert program), som hedder <interfacename +>Arts::TraderQuery</interfacename +> og <interfacename +>Arts::TraderOffer</interfacename +>. Du går på en <quote +>indkøbsrunde</quote +> efter komponenter sådan her: </para> + +<orderedlist> +<listitem> +<para +>Opret et forespørgselsobjekt: </para> +<programlisting +>Arts::TraderQuery query; +</programlisting> +</listitem> + +<listitem> +<para +>Angiv hvad du vil have. Som du så ovenfor, beskriver komponenter sig selv med egenskaber, som de sætter til visse værdier. Så at specificere hvad du vil have gøres ved at vælge komponenter som understøtter en vis værdi for en egenskab. Dette sker med metoden supports i TraderQuery: </para> + +<programlisting +>query.supports("Interface","Arts::PlayObject"); + query.supports("Extension","wav"); +</programlisting> +</listitem> + +<listitem> +<para +>Tilsidst udføres forespørgslen med metoden query. Derefter får du (forhåbentlig) nogle tilbud: </para> + +<programlisting +>vector<Arts::TraderOffer> *offers = query.query(); +</programlisting> +</listitem> + +<listitem> +<para +>Nu kan du undersøge hvad du fandt. Det vigtige er metoden interfaceName i TraderOffer, som giver dig navnene på komponenterne som svarede på spørgsmålet. Du kan også finde ud af yderligere egenskaber med getProperty. Følgende kode løber helt enkelt gennem alle komponenterne, udskriver deres grænsefladenavn (som ville kunne bruges til at oprette dem), og fjerner resultaterne af forespørgslen igen: </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 at denne slags handelsservice skal være nyttig, er det vigtigt på en eller anden måde at blive enig om hvilke egenskaber som komponenter normalt skal definere. Det er væsentligt at mere eller mindre alle komponenter indenfor et vist område bruger samme sæt egenskaber til at beskrive sig selv (og samme sæt værdier når det behøves), så programmer (eller andre komponenter) kan finde dem. </para> + +<para +>Author (type streng, valgfri): Forfatter. Dette kan bruges til endelig at lade verden finde ud af at du har skrevet noget. Du kan skrive hvad du vil her, en e-mail-adresse er naturligvis en god hjælp. </para> + +<para +>Buildable (type boolean, anbefales): Bygbar. Dette angiver om komponenten er brugbar med <acronym +>RAD</acronym +>-værktøj (såsom &arts-builder;) som bruger komponenter ved at tildele egenskaber og forbinde porte. Det anbefales at denne værdi sættes til true for næsten alle signalbehandlingskomponenter (såsom filer, lydeffekter, oscillatorer, ...), og for alle andre objekter som kan bruges på en <acronym +>RAD</acronym +>-lignende måde, men ikke for interne objekter som for eksempel <interfacename +>Arts::InterfaceRepo</interfacename +>. </para> + +<para +>Extension (type streng, brugt hvor det passer): Filendelse. Alle moduler som håndterer filer bør overveje at bruge dette. Du angiver filendelsen med små bogstaver uden <quote +>.</quote +> her, så noget som <userinput +>wav</userinput +> skulle virke udmærket. </para> + +<para +>Interface (type streng, kræves): Grænseflade. Dette skal omfatte hele listen af (nyttige) grænseflader som din komponent understøtter, formodentlig inklusive <interfacename +>Arts::Object</interfacename +> og hvis anvendeligt <interfacename +>Arts::SynthModule</interfacename +>. </para> + +<para +>Language (type streng, anbefales): Sprog. Hvis du ønsker at din komponent skal indlæses dynamisk, skal du angive sproget her. For øjeblikket er den eneste tilladte værdi <userinput +>C++</userinput +>, som betyder at komponenten er skrevet med den normale C++ programmeringsgrænseflade. Hvis du angiver dette, skal du også angive egenskaben <quote +>Library</quote +> nedenfor. </para> + +<para +>Library (type streng, brugt hvor det passer): Bibliotek. Komponenter som er skrevet i C++ kan indlæses dynamisk. For at gøre dette skal du kompilere dem i et dynamisk indlæseligt libtool (<literal role="extension" +>.la</literal +>) modul. Her kan du angive navnet på <literal role="extension" +>.la</literal +>-filen som indeholder din komponent. Husk at bruge REGISTER_IMPLEMENTATION (som altid). </para> + +<para +>MimeType (type streng, brug hvor det passer): Mimetype. Alle som håndterer filer bør overveje at bruge dette. Du skal angive standard-mimetypen med små bogstaver her, for eksempel <userinput +>audio/x-wav</userinput +>. </para> + +<para +>&URL; (type streng, valgfri): Hvis du vil fortælle hvor man kan finde en ny version af komponenten (eller en netside eller noget andet), kan du gøre dette. Dette skal være en standard &HTTP;- eller &FTP;-netadresse. </para> + +</sect1> + +<!-- TODO +<sect1 id="midi-synthesis"> +<title +><acronym +>MIDI</acronym +> Synthesis</title> + +</sect1> + +<sect1 id="instruments"> +<title +>Instruments</title> + +</sect1> + +<sect1 id="session-management"> +<title +>Session Management</title> + +</sect1> + +<sect1 id="full-duplex"> +<title +>Full duplex Audio</title> + +</sect1> +--> + +<sect1 id="namespaces"> +<title +>Navnerum i &arts;</title> + +<sect2 id="namespaces-intro"> +<title +>Indledning</title> + +<para +>Hver navnerumsdeklaration hører sammen med en deklaration af en <quote +>modul</quote +> i &MCOP; &IDL;. </para> + +<programlisting +>// mcop idl + +module M { + interface A + { + } +}; + +interface B; +</programlisting> + +<para +>I dette tilfælde ville den genererede C++ kode for &IDL;-fragmentet se sådan her ud: </para> + +<programlisting +>// C++ deklaration + +namespace M { + /* deklaration af A_base/A_skel/A_stub og lignende */ + class A { // Smartwrap referenceklasse + /* [...] */ + }; +} + +/* deklaration af B_base/B_skel/B_stub og lignende */ +class B { + /* [...] */ +}; +</programlisting> + +<para +>Så når du henviser til klasserne fra eksemplet ovenfor i din C++ kode, skal du skrive <classname +>M::A</classname +>, men kun B. Du kan imidlertid bruge <quote +>using M</quote +> et sted, som med alle navnerum i C++. </para> + +</sect2> + +<sect2 id="namespaces-how"> +<title +>Hvordan &arts; bruger navnerum</title> + +<para +>Der er et globalt navnerum som kaldes <quote +>Arts</quote +>, som alle programmer og biblioteker som hører til &arts; selv bruger til at lægge deres deklarationer i. Dette betyder at når du skriver C++ kode som afhænger af &arts;, skal du normalt bruge præfikset <classname +>Arts::</classname +> for hver klasse du bruger, sådan her: </para> + +<programlisting +>int main(int argc, char **argv) +{ + Arts::Dispatcher dispatcher; + Arts::SimpleSoundServer server(Arts::Reference("global:Arts_SimpleSoundServer")); + + server.play("/var/foo/nogen_fil.wav"); +</programlisting> + +<para +>Det andet alternativ er at skrive "using" en gang, sådan her: </para> + +<programlisting +>using namespace Arts; + +int main(int argc, char **argv) +{ + Dispatcher dispatcher; + SimpleSoundServer server(Reference("global:Arts_SimpleSoundServer")); + + server.play("/var/foo/nogen_fil.wav"); + [...] +</programlisting> + +<para +>I &IDL;-filer, har du egentlig ikke noget valg. Hvis du skriver kode som tilhører &arts; selv, skal du putte den i modulet &arts;. </para> + +<programlisting +>// IDL-fil for aRts-kode: +#include <artsflow.idl> +module Arts { // put den i Arts-navnerum + interface Synth_TWEAK : SynthModule + { + in audio stream invalue; + out audio stream outvalue; + attribute float tweakFactor; + }; +}; +</programlisting> + +<para +>Hvis du skriver kode som ikke hører til selve &arts;, skal du ikke putte den i navnerummet <quote +>Arts</quote +>. Du kan dog oprette et eget navnerum hvis du vil. Under alle omstændigheder, skal du bruge præfiks for klasser fra &arts; som du bruger. </para> + +<programlisting +>// IDL-fil for kode som ikke hører til aRts: +#include <artsflow.idl> + +// skriv enten med eller uden moduldeklaration, og de genererede klasser +// kommer ikke til at bruge et navnerum: +interface Synth_TWEAK2 : Arts::SynthModule +{ + in audio stream invalue; + out audio stream outvalue; + attribute float tweakFactor; +}; + +// du kan dog vælge et eget navnerum hvis du vil, så hvis du +// skriver programmet "PowerRadio", ville du kunne gøre sådan her: +module PowerRadio { + struct Station { + string name; + float frequency; + }; + + interface Tuner : Arts::SynthModule { + attribute Station station; // intet præfiks for Station, samme modul + out audio stream left, right; + }; +}; +</programlisting> + +</sect2> + +<sect2 id="namespaces-implementation"> +<title +>Interne funktioner: hvordan implementeringen virker</title> + +<para +>&MCOP; har ofte brug for at henvise til navne på typer og grænseflader for typekonverteringer, grænseflader og metodesignaturer. Disse repræsenteres af strenge i de almindelige &MCOP;-datastrukturer, mens navnerummet altid er fuldstændigt repræsenteret i C++ stilen. Dette betyder at strengene skal indeholde <quote +>M::A</quote +> og <quote +>B</quote +>, ifølge eksemplerne ovenfor. </para> + +<para +>Bemærk at dette til og med gælder hvis navnerumskvalifikatorerne ikke blev givet inde i &IDL;-teksten, eftersom sammenhængen klargør hvilket navnerum grænsefladen <interfacename +>A</interfacename +> var beregnet til at bruge. </para> + +</sect2> +</sect1> + +<sect1 id="threads"> +<title +>Tråde i &arts;</title> + +<sect2 id="threads-basics"> +<title +>Det basale</title> + +<para +>At bruge tråde er ikke muligt på alle platforme. Dette er grunden til at &arts; oprindeligt blev skrevet uden at bruge tråde overhovedet. For næsten alle problemer, findes der en løsning uden tråde som gør det samme som hvert løsning med tråde. </para> + +<para +>For eksempel, i stedet for at placere lyduddata i en separat tråd, og gøre den blokerende, bruger &arts; lyduddata som ikke blokerer, og regner ud hvornår næste del af uddata skal skrives med <function +>select()</function +>. </para> + +<para +>&arts; understøtter i det mindste (i de nyeste versioner) støtte for dem som vil implementere deres objekter med tråde. Hvis du for eksempel allerede har kode for en <literal role="extension" +>mp3</literal +>-afspiller, og koden forventer at <literal role="extension" +>mp3</literal +>-afkoderen skal køres i en separat tråd, er det oftest lettest at beholde denne konstruktion. </para> + +<para +>Implementeringen af &arts;/&MCOP; er opbygget ved at dele tilstanden mellem forskellige objekter på tydelige og mindre tydlige måder. En kort liste af delte tilstande omfatter: </para> + +<itemizedlist> +<listitem +><para +>Afsenderobjektet som laver &MCOP;-kommunikation </para> +</listitem> + +<listitem> +<para +>Referenceregningen (Smartwrappers). </para> +</listitem> + +<listitem> +<para +>I/O-håndteringen som håndterer tidsgrænser og fd-tidsmåling. </para> +</listitem> + +<listitem> +<para +>Objekthåndteringen som laver objekter og indlæser plugin dynamisk. </para> +</listitem> + +<listitem> +<para +>Flydesystemet som kalder calculateBlock i passende tilfælde. </para> +</listitem> +</itemizedlist> + +<para +>Ingen af de ovenstående objekter forventer at blive brugt samtidigt (dvs. at blive kaldt fra forskellige tråde samtidigt). I almindelighed er der to måder at løse dette: </para> + +<itemizedlist> +<listitem> +<para +>Kræv at den som kalder hvilken som helst funktion i objektet skaffer sig en lås inden den bruges. </para> +</listitem> + +<listitem> +<para +>Gør objekterne virkeligt trådsikre og/eller opret instanser af dem for hver tråd. </para> +</listitem> +</itemizedlist> + +<para +>&arts; bruger den første måde. Du behøver en lås hver gang du skal have adgang til et af disse objekter. Den anden måde er sværere at gøre. Et hurtigt fiks som forsøger at opnå dette findes på <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 +>, men for øjeblikket virker en minimal måde formodentlig bedre, og forårsager mindre problemer med eksisterende programmer. </para> + +</sect2> +<sect2 id="threads-locking"> +<title +>Hvornår/hvordan skal låsning ske?</title> + +<para +>Du kan få/slippe låsen med de to funktioner: </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 +>Generelt behøver du ikke at skaffe en lås (og du skal ikke forsøge at gøre det), hvis den allerede holdes. En liste over betingelser når dette er tilfældet er: </para> + +<itemizedlist> +<listitem> +<para +>Du tager imod et tilbagekald fra I/O-håndteringen (tidsgrænse eller fd). </para> +</listitem> + +<listitem> +<para +>Du kaldes på grund af nogle &MCOP;-forespørgsler. </para> +</listitem> + +<listitem> +<para +>Du kaldes fra NotificationManager. </para> +</listitem> + +<listitem> +<para +>Du kaldes fra flydesystemet (calculateBlock) </para> +</listitem> +</itemizedlist> + +<para +>Der er også nogle undtagelse for funktioner som du kun kan kalde i hovedtråden, og af den grund aldrig behøver et låse for at kalde dem: </para> + +<itemizedlist> +<listitem> +<para +>Opret og fjern afsenderen eller I/O-håndteringen. </para> +</listitem> + +<listitem> +<para +><methodname +>Dispatcher::run()</methodname +> / <methodname +>IOManager::run()</methodname +> </para> +</listitem> + +<listitem> +<para +><methodname +>IOManager::processOneEvent()</methodname +></para> +</listitem> +</itemizedlist> + +<para +>Men det er alt. For alt andet som på nogen måde hører sammen med &arts;, skal du skaffe låsen, og slippe den igen når du er klar. Her er et enkelt eksempel: </para> + +<programlisting +>class SuspendTimeThread : Arts::Thread { +public: + void run() { + /* + * du behøver denne lås fordi: + * - oprettelse af en reference behøver en lås (eftersom global: går til + * objekthåndteringen, som derefter kunne have brug for GlobalComm + * objektet for at slå hver forbindelse der skal gøres op) + * - tildeling af en smartwrapper behøver en lås + * - oprettelse af et objekt fra en reference behøver en lås (eftersom + * den kan få brug for at forbinde til en server) + */ + Arts::Dispatcher::lock(); + Arts::SoundServer server = Arts::Reference("global:Arts_SoundServer"); + Arts::Dispatcher::unlock(); + + for(;;) { /* + * du behøver en lås her, eftersom + * - følge en reference for en smartwrapper behøver en lås + * (eftersom den kan oprette objektet når den bruges) + * - at gøre et MCOP-kald behøver en lås + */ + Arts::Dispatcher::lock(); + long seconds = server.secondsUntilSuspend(); + Arts::Dispatcher::unlock(); + + printf("sekunder til ventetilstand = %d",seconds); + sleep(1); + } + } +} +</programlisting> + + +</sect2> + +<sect2 id="threads-classes"> +<title +>Trådrelaterede klasser</title> + +<para +>Følgende trådrelaterede klasser er tilgængelige for øjeblikket: </para> + +<itemizedlist> +<listitem> +<para +><ulink url="http://www.arts-project.org/doc/headers/Arts__Thread.html" +><classname +> Arts::Thread</classname +></ulink +> - som indkapsler en tråd. </para> +</listitem> + +<listitem> +<para +><ulink url="http://www.arts-project.org/doc/headers/Arts__Mutex.html" +> <classname +>Arts::Mutex</classname +></ulink +> - som indkapsler en mutex. </para> +</listitem> + +<listitem> +<para +><ulink url="http://www.arts-project.org/doc/headers/Arts__ThreadCondition.html" +> <classname +>Arts::ThreadCondition</classname +></ulink +> - som giver støtte for at vække tråde som venter på at en vis betingelse skal blive sand. </para> +</listitem> + +<listitem> +<para +><ulink url="http://www.arts-project.org/doc/headers/Arts__SystemThreads.html" +><classname +>Arts::SystemThreads</classname +></ulink +> - som indkapsler operativsystemets trådningslager (og giver nogle hjælpefunktioner for anvendelsesprogrammører). </para> +</listitem> +</itemizedlist> + +<para +>Se linkene for dokumentationen. </para> + +</sect2> +</sect1> + +<sect1 id="references-errors"> +<title +>Referencer og fejlhåndtering</title> + +<para +>&MCOP;-referencer er et af de mest centrale begreber i &MCOP; programmering. Dette afsnit forsøger at beskrive nøjagtigt hvordan referencer bruges, og behandler især fejltilfælde (server bryder sammen). </para> + +<sect2 id="references-properties"> +<title +>Grundlæggende egenskaber for referencer</title> + +<itemizedlist> +<listitem> +<para +>En &MCOP; reference er ikke et objekt, men en reference til et objekt: Selv om følgende deklaration <programlisting> + Arts::Synth_PLAY p; +</programlisting +> ser ud som en definition af et objekt, så deklarerer den kun en reference til et objekt. Som C++ programmør, kan du også se den som Synth_PLAY *, en slags peger til et Synth_PLAY-objekt. Det betyder specielt at p kan være det samme som en NULL-peger. </para> +</listitem> + +<listitem> +<para +>Du kan oprette en NULL-reference ved eksplicit at tildele den. </para> +<programlisting +>Arts::Synth_PLAY p = Arts::Synth_PLAY::null(); +</programlisting> +</listitem> + +<listitem> +<para +>At kalde objekter med en NULL-reference forårsager et hukommelsesdump </para> +<programlisting +>Arts::Synth_PLAY p = Arts::Synth_PLAY::null(); + string s = p.toString(); +</programlisting> +<para +>forårsager et hukommelsesdump. Hvis man sammenligner dette med en peger, er det stort set det samme som <programlisting> + QWindow* w = 0; + w->show(); +</programlisting +> hvilket enhver C++ programmør ved at man skal undgå. </para> +</listitem> + +<listitem> +<para +>Uinitierede objekter forsøger at oprette sig selv når de først bruges </para> + +<programlisting +>Arts::Synth_PLAY p; + string s = p.toString(); +</programlisting> +<para +>er noget anderledes end at følge en NULL-peger. Du fortalte slet ikke objektet hvad det er, og nu forsøger du at bruge det. Gætværket her er at du vil have en ny lokal instans af et Arts::Synth_PLAY-objekt. Du kan naturligvis have villet gøre noget andet (såsom at oprette objektet et andet sted, eller bruge et eksisterende fjernobjekt). Det er i alle tilfælde en bekvem genvej til at oprette objekter. At oprette et objekt når det først bruges virker ikke når du allerede har tildelt det til noget andet (som en null-reference). </para> + +<para +>Den tilsvarende C++ terminologi ville være <programlisting> + QWidget* w; + w->show(); +</programlisting +> som naturligvis helt enkelt giver en segmenteringsfejl i C++. Så dette er anderledes her. Denne måde at oprette objekt er tricket, eftersom det ikke er nødvendigt at der findes en implementering for din grænseflade. </para> + +<para +>Betragt for eksempel et abstrakt objekt såsom et Arts::PlayObject. Der er naturligvis konkrete PlayObjects, såsom de til for at afspille mp3-filer eller wav-filer, men <programlisting> + Arts::PlayObject po; + po.play(); +</programlisting +> mislykkes helt sikkert. Problemet er at selvom et PlayObject forsøges at blive lavet, så mislykkes det eftersom der kun er objekter såsom Arts::WavPlayObject og lignende. Brug derfor kun denne måde at oprette objekter hvis du er sikker på at der er en implementering. </para> +</listitem> + +<listitem> +<para +>Referencer kan pege på samme objekt </para> + +<programlisting +>Arts::SimpleSoundServer s = Arts::Reference("global:Arts_SimpleSoundServer"); + Arts::SimpleSoundServer s2 = s; +</programlisting> + +<para +>laver to referencer som angiver samme objekt. Det kopierer ikke nogen værdi, og laver ikke to objekter. </para> +</listitem> + +<listitem> +<para +>Alle objekter referenceregnes. Så snart et objekt ikke har nogen referencer længere, slettes det. Der er ingen måde udtrykkeligt at fjerne et objekt, men du kan dog bruge noget sådant her <programlisting> + Arts::Synth_PLAY p; + p.start(); + [...] + p = Arts::Synth_PLAY::null(); +</programlisting +> for at få Synth_PLAY-objektet til at forsvinde til slut. Specielt er det aldrig nødvendigt at bruge new og delete i sammenhæng med referencer. </para> +</listitem> +</itemizedlist> + +</sect2> + +<sect2 id="references-failure"> +<title +>Tilfældet hvor det mislykkes</title> + +<para +>Eftersom referencer kan pege på fjernobjekter, kan serverne som indeholder disse objekter bryde sammen. Hvad sker så? </para> + +<itemizedlist> + +<listitem> +<para +>Et sammenbrud ændrer ikke om en reference er en null-reference. Dette betyder at hvis <function +>foo.isNull()</function +> var <returnvalue +>true</returnvalue +> inden et serversammenbrud er den også <returnvalue +>true</returnvalue +> efter et serversammenbrud (hvilket er indlysende). Det betyder også at hvis <function +>foo.isNull()</function +> var <returnvalue +>false</returnvalue +> inden et serversammenbrud (foo angav et objekt) er den også <returnvalue +>false</returnvalue +> efter serversammenbruddet. </para> +</listitem> + +<listitem> +<para +>At kalde metoder med en gyldig reference forbliver sikkert. Antag at serveren som indeholder objektet calc brød sammen. Kald til objekter såsom <programlisting> + int k = calc.subtract(i,j) +</programlisting +> er stadigvæk sikre. Det er åbenbart at subtract skal returnere noget, hvilket den ikke kan eftersom fjernobjektet ikke længere findes. I dette tilfælde ville (k == 0) være sand. I almindelighed forsøger operationer at returnere noget <quote +>neutralt</quote +> som resultat, såsom 0.0, en null-reference for objekter eller tomme strenge, når objektet ikke længere findes. </para> +</listitem> + +<listitem> +<para +>Kontrol med <function +>error()</function +> afslører om noget virkede. </para> + +<para +>I ovenstående tilfælde, ville <programlisting> + int k = calc.subtract(i,j) + if(k.error()) { + printf("k er ikke i-j!\n"); + } +</programlisting +> udskrive <computeroutput +>k er ikke i-j</computeroutput +> når fjernkaldet ikke virkede. Ellers er <varname +>k</varname +> virkelig resultatet af subtraktionsoperationen som udføres af fjernobjektet (intet serversammenbrud). For metoder som gør ting såsom at fjerne en fil, kan du ikke vide med sikkerhed om det virkelig er sket. Naturligvis skete det hvis <function +>.error()</function +> er <returnvalue +>false</returnvalue +>. Men hvis <function +>.error()</function +> er <returnvalue +>true</returnvalue +>, er der to muligheder: </para> + +<itemizedlist> +<listitem> +<para +>Filen blev slettet, og serveren brød sammen præcis efter den blev slette, men inden resultatet overførtes. </para> +</listitem> + +<listitem> +<para +>Serveren brød sammen inden den kunne fjerne filen. </para> +</listitem> +</itemizedlist> +</listitem> + +<listitem> +<para +>Brug af indlejrede kald er farligt i et program som skal være sikkert mod sammenbrud. </para> + +<para +>Brug af noget i retning af <programlisting> + window.titlebar().setTitle("foo"); +</programlisting +> er ikke en god idé. Antag at du ved at vinduet indeholder en gyldig vinduesreference. Antag at du ved at <function +>window.titlebar()</function +> returnerer en reference til navnelisten eftersom vinduesobjektet er rigtigt implementeret. Sætningen ovenfor er imidlertid alligevel ikke sikker. </para> + +<para +>Hvad kan ske hvis serveren som indeholder vinduesobjektet er brudt sammen. Så vil du, uafhængig af hvor god implementeringen af Window er, få en null-reference som resultat af operationen window.titlebar(). Og derefter vil kaldet til setTitle med denne null-reference naturligvis også føre til et sammenbrud. </para> + +<para +>Så en sikker variant af dette ville være <programlisting> + Titlebar titlebar = window.titlebar(); + if(!window.error()) + titlebar.setTitle("foo"); +</programlisting +> og tilføj den rigtige fejlhåndtering hvis du vil. Hvis du ikke stoler på implementeringen af Window, kan du lige så godt bruge <programlisting> + Titlebar titlebar = window.titlebar(); + if(!titlebar.isNull()) + titlebar.setTitle("foo"); +</programlisting +> som begge er sikre. </para> +</listitem> +</itemizedlist> + +<para +>Der er andre fejlbetingelser, såsom nedkobling af netværket (antag at du tager kablet mellem din server og klient væk mens dit program kører). Deres effekt er imidlertid den samme som et serversammenbrud. </para> + +<para +>Totalt set er det naturligvis et policy-spørgsmål hvor strengt du forsøger at håndtere kommunikationsfejl i hele dit program. Du kan følge metoden <quote +>hvis serveren bryder sammen, skal vi fejlsøge den til den aldrig bryder sammen igen</quote +>, som ville betyde at du ikke behøver bryde dig om alle disse problemer. </para> + +</sect2> + +<sect2 id="references-internals"> +<title +>Interne funktioner: distribueret referenceregning</title> + +<para +>Et objekt skal ejes af nogen for at eksistere. Hvis det ikke gør det, vil det ophøre med at eksistere (mere eller mindre) med det samme. Internt angives en ejer ved at kalde <function +>_copy()</function +>, som forøger en reference tæller, og en ejer fjernes ved at kalde <function +>_release()</function +>. Så snart referencetælleren når nul, så slettes objektet. </para> + +<para +>Som en variation på temaet, angives fjernbrug med <function +>_useRemote()</function +>, og opløses med <function +>_releaseRemote()</function +>. Disse funktioner har en liste over hvilken server som har kaldt dem (og derfor ejer objektet). Dette bruges hvis serveren kobler ned (dvs. sammenbrud, netværksfejl), for at fjerne referencer som stadigvæk findes til objektet. Dette gøres i <function +>_disconnectRemote()</function +>. </para> + +<para +>Nu er der et problem. Betragt en returværdi. I almindelige tilfælde ejes returværdiobjektet ikke af funktionen som kaldes længere. Det ejes heller ikke af den som kalder, førend meddelelsen som indeholder objektet er modtaget. Så der er en tid med objekter som <quote +>mangler ejere</quote +>. </para> + +<para +>Når vi nu sender et objekt kan man være rimeligt sikker på at så snart det modtages, ejes det af nogen igen, med mindre, igen, modtageren bryder sammen. Dette betyder i alle tilfælde at specielle hensyn skal tages for objekter i det mindste mens der sendes, og formodentlig også mens der modtages, så de ikke fjernes med det samme. </para> + +<para +>Måden som &MCOP; gør dette er ved at <quote +>mærke</quote +> objekter som er ved at blive kopieret over netværket. Inden en sådan kopiering begynder, kaldes <function +>_copyRemote</function +>. Dette forhindrer at objektet fjernes et stykke tid (5 sekunder). Så snart modtageren kalder <function +>_useRemote()</function +>, fjernes mærket igen. Så alle objekter som sendes over netværket, mærkes inden overførslen. </para> + +<para +>Hvis modtageren modtager et objekt som findes på samme server, så bruges <function +>_useRemote()</function +> naturligvis ikke. I dette specialtilfælde, findes funktionen <function +>_cancelCopyRemote()</function +> til at fjerne mærket manuelt. Foruden dette, er der også en tidsbaseret fjernelse af mærker, hvis mærkning udførtes, men modtageren ikke virkelig fik objektet (på grund af sammenbrud, netværksfejl). Dette gøres med klassen <classname +>ReferenceClean</classname +>. </para> + +</sect2> + +</sect1> + +<sect1 id="detail-gui-elements"> +<title +>&GUI;-elementer</title> + +<para +>&GUI;-elementer er for øjeblikket på det eksperimentelle stadium. Dette afsnit beskriver hvad det er meningen der skal ske med dem, så hvis du er udvikler, kan du forstå hvordan &arts; vil håndtere grafiske grænseflader i fremtiden. Der er også allerede en del kode på plads. </para> + +<para +>&GUI;-elementer skal bruges til at lade syntesestrukturer vekselvirke med brugeren. I det enkleste tilfælde skal brugeren kunne ændre nogle parametre for en struktur direkte (som en forstærkningsfaktor som bruges inden det endelige afspilningsmodul). </para> + +<para +>I mere komplekse tilfælde, kan man tænke sig at brugeren ændrer parametre for grupper af strukturer og/eller strukturer som ikke kører endnu, såsom at ændre <acronym +>ADSR</acronym +> enveloppen for det aktive &MIDI;-instrument. Noget andet ville kunne være at angive filnavnet for et samplingsbaseret instrument. </para +> + +<para +>På den anden side, kunne brugeren ville overvåge hvad syntheziseren gør. Der kunne være oscilloskoper, spektrumanalysatorer, lydstyrkemålere og <quote +>eksperimenter</quote +> som for eksempel regner frekvensoverførselskurven ud for et given filtermodul. </para> + +<para +>Til sidst, skal &GUI;-elementer kunne kontrollere hele strukturen af alt som kører inden i &arts;, og på hvilken måde. Brugeren skal kunne tildele instrumenter til midi-kanaler, starte nye effektbehandlingsskridt, indstille sit hovedmikserpanel (som selv er opbygget af &arts;-strukturer) for at få yderligere en kanal eller bruge en anden strategi for tonekontrol. </para> + +<para +>Som du ser, skal &GUI;-elementer give alle mulighederne i et virtuelt studie som &arts; simulerer for brugeren. Naturligvis skal de også vekselvirke med midi-indgange (såsom skydere som også flyttes hvis de får &MIDI;-inddata som ændrer tilsvarende parametre), og formodentlig til og med oprette begivenheder selv, for at vekselvirkning med brugeren skal kunne indspilles via en sequencer. </para> + +<para +>Teknisk set er idéen at have en &IDL;-basisklasse for alle grafiske komponenter (<classname +>Arts::Widget</classname +>), og aflede et antal almindelige komponenter fra den (såsom <classname +>Arts::Poti</classname +>, <classname +>Arts::Panel</classname +>, <classname +>Arts::Window</classname +>, ...). </para> + +<para +>Derefter kan man implementere disse grafiske komponenter med en værktøjskasse, for eksempel &Qt; eller Gtk. Til slut, bør effekter bygge deres grafiske grænseflader fra eksisterende komponenter. En efterklangseffekt ville for eksempel kunne bygge sin grafiske grænseflade fra fem <classname +>Arts::Poti</classname +>-tingester og et <classname +>Arts::Window</classname +>. Så HVIS der findes en &Qt; implementering for disse grundkomponenter, kan effekten vises med &Qt;. Hvis der findes en Gtk implementering, virker det også med Gtk (og ser mere eller mindre ud på samme måde). </para> + +<para +>Til sidst, eftersom vi bruger &IDL; her, kan &arts-builder; (eller andre værktøjer) sætte grafiske grænseflader sammen visuelt, eller generere grafiske grænseflader automatisk, med tips for parameterværdier, kun baseret på grænsefladen. Det burde være ganske ligetil at skrive en klasse til at <quote +>oprette grafisk grænseflader fra en beskrivelse</quote +>, som tager en beskrivelse af en grafisk grænseflade (som indeholder de forskellige parametre og grafiske komponenter), og laver et levende objekt for en grafisk grænseflade ud fra den. </para> + +<para +>Baseret på &IDL; og &arts;/&MCOP;-komponentmodellen, bør det være let at udvide de mulige objekter som kan bruges til den grafiske grænseflade præcis lige så let som det er at tilføje et plugin til &arts; som for eksempel implementerer et nyt filter. </para> + +</sect1> + +</chapter> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/digitalaudio.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/digitalaudio.docbook new file mode 100644 index 00000000000..fb8305b53f4 --- /dev/null +++ b/tde-i18n-da/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 +>Indledning til digital lyd</title> + +<para +>Digital sampling, filtre, lydeffekter, &etc;.</para> + +</appendix> + + + diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/faq.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/faq.docbook new file mode 100644 index 00000000000..0476961bd72 --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/faq.docbook @@ -0,0 +1,1307 @@ +<!-- <?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 +>Spørgsmål og svar</title> + +<para +>Dette afsnit besvarer nogle spørgsmål som ofte stilles om &arts;. </para> + +<qandaset id="faq-general"> +<title +>Generelle spørgsmål</title> + +<qandaentry> +<question> +<para +>Støtter &kde; mit lydkort for lydafspilning? </para> +</question> + +<answer> +<para +>&kde; bruger &arts; til at afspille lyd, og &arts; bruger driverne kernen for &Linux;, enten <acronym +>OSS</acronym +> eller <acronym +>ALSA</acronym +> (med emulering af <acronym +>OSS</acronym +>). Hvis dit lydkort enten understøttes af <acronym +>ALSA</acronym +> eller <acronym +>OSS</acronym +> og er rigtigt indstillet (dvs. alle andre &Linux;-programmer kan afspille lyd), kommer det til at virke. Der er dog nogle problemer med specifik hardware, læs <link linkend="faq-hardware-specific" +>afsnittet om hardwarespecifikke problemer</link +> hvis du har problemer med artsd på din maskine. </para> +<para +>I mellemtiderne er støtte for diverse andre platforme også tilføjet. Her er en fuldstændig liste over hvordan den seneste version af &arts; kan afspille lyd. Hvis du har en platform som ikke understøttes, så overvej gerne at overføre &arts; til din platform. </para> + +<informaltable> +<tgroup cols="2"> +<thead> +<row> +<entry +>&arts; metode for lyd-I/O</entry> +<entry +>Kommentar</entry> +</row> +</thead> + +<tbody> +<row> +<entry +>paud</entry> +<entry +>Støtte for AIX personlige lydenhed (Personal Audio Device)</entry> +</row> + +<row> +<entry +>alsa</entry> +<entry +>Linux ALSA-0.5 og ALSA-0.9 drivere</entry> +</row> + +<row> +<entry +>libaudioio</entry> +<entry +>Støtte for det generelle LibAudioIO-bibliotek som virker på Solaris</entry> +</row> + +<row> +<entry +>nas</entry> +<entry +>NAS lydserver, nyttig for X-terminaler med NAS-støtte</entry> +</row> + +<row> +<entry +>null</entry> +<entry +>Lydenheden null, kasserer lyden uden at noget høres</entry> +</row> + +<row> +<entry +>oss</entry> +<entry +>OSS (Open Sound System) støtte (virker på Linux, forskellige BSD-versioner og andre platforme med OSS-drivere installerede)</entry> +</row> + +<row> +<entry +>toss</entry> +<entry +>Trådet OSS-støtte, som virker bedre i visse tilfælde når den almindelige OSS-støtte ikke virker godt</entry> +</row> + +<row> +<entry +>sgi</entry> +<entry +>Støtte for SGI Direct Media for IRIX</entry> +</row> + +<row> +<entry +>sun</entry> +<entry +>Solaris-støtte</entry> +</row> + +</tbody> +</tgroup> +</informaltable> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Jeg kan ikke spille <literal role="extension" +>wav</literal +>-filer med &artsd;! </para> +</question> + +<answer> +<para +>Tjek at &artsd; er linket til <filename +>libaudiofile</filename +> (<userinput +><command +>ldd</command +> <parameter +>artsd</parameter +></userinput +>). Hvis den ikke er det, så hent tdesupport, kompilér alt, og det vil virke. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Jeg hører lyd når jeg er logget på som <systemitem class="username" +>root</systemitem +>, men ingen andre brugere har lyd! </para> +</question> + +<answer> +<para +>Tilladelserne for filen <filename class="devicefile" +>/dev/dsp</filename +> påvirker hvilke brugere der har lyd. For at lade alle bruge den, gør sådan her: </para> + +<procedure> +<step> +<para +>Log ind som <systemitem class="username" +>root</systemitem +>. </para> +</step> + +<step> +<para +>Åbn et &konqueror;-vindue. </para> +</step> + +<step> +<para +>Gå til mappen <filename class="directory" +>/dev</filename +>. </para> +</step> + +<step> +<para +>Klik på filen <filename +>dsp</filename +> med <mousebutton +>højre</mousebutton +> museknap, og vælg egenskaber. </para> +</step> + +<step> +<para +>Klik på fanebladet <guilabel +>Tilladelser</guilabel +>. </para> +</step> + +<step> +<para +>Markér <guilabel +>Læs</guilabel +> og <guilabel +>Skriv</guilabel +> i alle afsnit. </para> +</step> + +<step> +<para +>Klik på <guibutton +>O.k.</guibutton +>. </para> +</step> +</procedure> + +<para +>Du kan opnå samme virkning i et terminalvindue med kommandoen <userinput +><command +>chmod</command +> <option +>666</option +> <parameter +>/dev/dsp</parameter +></userinput +>. </para> + +<para +>For at begrænse adgangen af lyd til særlige brugere kan du bruge gruppetilladelser. For visse &Linux;-distributioner, for eksempel Debian/Potato, ejes <filename class="devicefile" +>/dev/dsp</filename +> allerede af en gruppe som hedder <systemitem class="groupname" +>audio</systemitem +>, så alt du behøver gøre er at tilføje brugerne til denne gruppe. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Dette hjælper for &artsd;, men hvad med for &kmix;, &kmid;, &kscd;? </para> +</question> +<answer> + +<para +>Der er forskellige andre enheder som sørger for funktioner som der skal være adgang til for multimedieprogrammer. Du kan behandle dem på samme måde, enten ved at gøre dem tilgængelige for alle, eller bruge grupper for at kontrollere adgangen. Her er en liste, som måske stadigvæk er ufuldstændig (og hvis der er flere enheder på formen <filename class="devicefile" +>midi0</filename +>, <filename class="devicefile" +>midi1</filename +>..., så er 0-versionen kun med): </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 +>Hvad kan jeg gøre hvis artsd ikke starter eller bryder sammen når den kører?</para> +</question> + +<answer> +<para +>Forsøg først at bruge standardindstillingerne i &kcontrol; (eller hvis du starter manuelt, angive ingen ekstra flag bortset fra eventuelt <userinput +><option +>-F</option +><parameter +>10</parameter +> <option +>-S</option +><parameter +>4096</parameter +></userinput +> for latenstid). Særlig <emphasis +>fuld dupleks virker formodentlig ikke</emphasis +> med diverse drivere, så forsøg at deaktivere det. </para> + +<para +>En god måde at regne ud hvorfor &artsd; ikke starter (eller bryder sammen når den kørt) er at starte den manuelt. Åbn et &konsole;-vindue og skriv: </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 +>Du kan også tilføje flaget <option +>-l0</option +>, som udskriver mere information om hvad der sker, sådan her: </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 +>Ved at gøre dette får du formodentlig nogen nyttig information om hvorfor den ikke startede. Eller hvis den bryder sammen mens noget særligt foregår, kan du gøre det og se <quote +>hvordan</quote +> den bryder sammen. Hvis du vil rapportere en fejl, kan et backtrace oprettet med <command +>gdb</command +> og/eller en <command +>strace</command +> hjælpe med til at finde problemet. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Kan jeg flytte &artsd; (flytte kompilerede filer til en anden mappe)?</para> +</question> + +<answer> +<para +>Du kan ikke flytte &arts; helt perfekt. Problemet er at &artswrapper; har stedet for &artsd; indkompileret af sikkerhedsgrunde. Du kan imidlertid bruge <filename +>.mcoprc</filename +>-filen (TraderPath/ExtensionPath indgangene) til i det mindste at få en flyttet &artsd; til at finde sine komponenter. Se <link linkend="the-mcoprc-file" +>kapitlet om <filename +>.mcoprc</filename +>-filen</link +> for detaljer om hvordan man gør dette. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Kan jeg kompilere &arts; med gcc-3.0?</para> +</question> + +<answer> +<para +>Et kort svar: nej, &arts; virker ikke hvis du kompilerer den med gcc-3.0. </para> + +<para +>Langt svar: i den officielle udgave af gcc-3.0, er der to fejl som påvirker &arts;. Det første problem med gcc-3.0, c++/2733, er ganske ufarligt (og har at gøre med problemer med asm-sætningen). Det gør at convert.cc ikke kan kompileres. Dette er rettet i gcc-3.0 CVS, og vil ikke være et problem med gcc-3.0.1 og senere. En måde at gå udenom problemet er også tilføjet i CVS-versionen af KDE/aRts. </para> +<para +>Det andet problem med gcc-3.0, c++/3145 (som forårsager fejlagtig kodegenerering i visse tilfælde af multipel virtuel arv) er kritisk. Programmer som &artsd; bryder helt enkelt sammen når de startes hvis de er kompileret med gcc-3.0. Selvom visse fremskridt er gjort i gcc-3.0 grenen når dette skrives, bryder &artsd; stadigvæk vældigt ofte sammen, uforudsigeligt. </para> +</answer> +</qandaentry> +<qandaentry> +<question> +<para +>Hvilke programmer kører med &arts;?</para> +</question> +<answer> + +<para +>Selvfølgelig så virker alle programmer som indgår i &kde; med &arts;. Dette omfatter: </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;-spil såsom &kpoker; og &ktuberling;</para +></listitem> +</itemizedlist> + +<para +>Visse &kde;-programmer som endnu ikke indgår i &kde;-udgaver (f.eks. i kdenonbeta) understøtter også &arts;, inklusive: </para> + +<itemizedlist> +<listitem +><para +>&brahms;</para +></listitem> +<listitem +><para +><application +>Kaboodle</application +></para +></listitem> +<listitem +><para +><application +>Kdao</application +></para +></listitem> +</itemizedlist> + +<para +>Følgende programmer som ikke hører til -&kde; er kendte for at virke med &arts;: </para> + +<itemizedlist> +<listitem +><para +><application +>xmms</application +> (med &arts;-plugin)</para +></listitem> +<listitem +><para +>Real Networks <application +>RealPlayer</application +> 8.0 (virker med &artsdsp;; indbygget &arts;-støtte overvejes)</para +></listitem> +</itemizedlist> + +<para +>Følgende programmer er kendte for <emphasis +>ikke</emphasis +> at virke med &arts;: </para> + +<itemizedlist> +<listitem +><para +>ingen</para +></listitem> +</itemizedlist> + +<para +>Se også svarene på spørgsmålene i afsnittet om <link linkend="faq-non-arts" +>programmer som ikke understøtter &arts;</link +>. </para> + +<para +>Dette afsnit er ufuldstændigt. Hvis du har mere information om programmer som understøttes eller ej, så vær venlig at sende dem til forfatteren så at de kan tilføjes her. </para> +</answer> +</qandaentry> + +</qandaset> + +<qandaset id="faq-non-arts"> +<title +>Programmer som ikke understøtter &arts;</title> + +<qandaentry> +<question> +<para +>Så snart &kde; kører, så kan ingen andre programmer få adgang til mit lydkort! </para> +</question> +<answer> +<para +>Når &arts;-lydserveren som bruges af &kde; kører, bruger den lydenheden. Hvis serveren er i tomgang i 60 sekunder, går den i autosuspension og slipper enheden automatisk. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Du sagde at den går i autosuspension efter 60 sekunder, det gør den ikke for mig! </para> +</question> +<answer> +<para +>Hvis du starter artsd fra KDE's kontrolcenter, er det standardværdien at gå i autosuspension efter 60 sekunder. Hvis du starter artsd fra kommandolinjen skal du bruge flaget -s for at angive ventetilstandsværdien, ellers er det standardopførsel at lukke af for autosuspensionsfunktionen. </para> +<para +>For øjeblikket går serveren ikke i autosuspension hvis fuld dupleks bruges. Luk af for fuld dupleks i kontrolcentret så går den i autosuspension. At lukke af for fuld dupleks er i almindelighed en god idé alligevel, hvis du kun bruger &arts; til at afspille lyd og ikke til at indspille. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Hvordan kan jeg køre gamle programmer som ikke understøtter &arts;? </para> +</question> + +<answer> +<para +>Kør dem med &artsdsp;. Hvis du for eksempel normalt ville køre: </para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>mpg123</command +> <option +>foo.mp3</option +></userinput +></screen> + +<para +>så brug i stedet:</para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>artsdsp</command +> <option +>mpg123 foo.mp3</option +></userinput +></screen> + +<para +>Dette sender lyduddata til &arts;. Denne metode kræver ikke nogen ændringer i programmet. Det er noget af et grimt fiks, og understøtter endnu ikke alle funktioner i lydkortsenheden, så visse programmer virker måske ikke. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Jeg kan ikke køre &artsdsp; med noget program. Den bryder altid sammen! </para> +</question> +<answer> +<para +>Du behøver en ny udgave af glibc-bilblioteket. &artsdsp; virker ikke tilforladeligt på visse ældre &Linux;-distributioner. For eksempel på Debian 2.1 (som er baseret på glibc 2.0) virker den ikke, mens den gør det på Debian 2.2 (som er baseret på glibc 2.1.3). </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Er der teoretiske begrænsninger med visse programmer som forhindrer at de nogensinde kan virke med &artsdsp;? </para> +</question> +<answer> +<para +>Nej. Brugen &artsdsp; kan resultere i noget højere latenstider og <acronym +>CPU</acronym +>-brug end at bruge &arts; programmeringsgrænseflade direkte. Udover det, skal alle program som ikke virker anses som en fejl i &artsdsp;. Teknikken som bruges af &artsdsp; skal, hvis den er rigtigt implementeret, tillade <emphasis +>hvert</emphasis +> program at virke med den (inklusive store programmer såsom <application +>Quake</application +> 3). </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Hvad kan jeg gøre hvis et program ikke virker med &artsdsp;? </para> +</question> +<answer> +<para +>Du kan vente på at &artsd; går i autosuspension eller bruge kommandoen <userinput +><command +>artsshell</command +> <option +>suspend</option +></userinput +> for at bede at servere om at gå i autosuspension. Du kommer kun til at kunne få serveren til at gå i autosuspension hvis intet &arts;-program bruger den for øjeblikket, og ingen &arts;-programmer kan køre mens serveren er i autosuspension. </para> + +<para +>Hvis serveren er optaget ser en grov men effektivt måde at slippe af med den sådan her ud: </para> + + +<screen +><prompt +>%</prompt +> <userinput +><command +>killall</command +> <option +>artsd</option +> ; <command +>killall</command +> <option +>artswrapper</option +></userinput> +<lineannotation +>Start nu dit eget program.</lineannotation> +<prompt +>%</prompt +> <userinput +><command +>kcminit</command +> <option +>arts</option +></userinput +> +</screen> + +<para +>Alle &arts;-programmer som kører lige nu kan bryde sammen, når du afslutter serveren. </para> +</answer> +</qandaentry> +<qandaentry> +<question> +<para +>Hvad gælder for programmer skrevet for &kde; 1.x? </para> +</question> +<answer> +<para +>Hvis du kører &kde; 1.x programmer, som afspiller lyd via lydserveren i &kde; 1, skal du køre <application +>kaudioserver</application +> for at det skal virke. Du kan starte <application +>kaudioserver</application +> på samme måde som andre programmer som ikke understøtter &arts;: </para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>artsdsp</command +> <option +>kaudioserver</option +></userinput +> +</screen> + +<para +>Du skal have installeret kaudioserver (fra samme kilde hvor du skaffede &kde; 1.x programmerne). Den hører til &kde; 1.x, ikke &kde; 2. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Hvad gælder for programmer som bruger Enlightened Sound Daemon, <acronym +>ESD</acronym +>? </para> +</question> +<answer> +<para +>Dette problem ligner tilfældet med <application +>kaudioserver</application +>. Sådanne programmer kræver en esd-server som kører. Du kan starte <command +>esd</command +> via &artsdsp;, og alle programmer som understøtter <acronym +>ESD</acronym +> vil så virke godt, sådan her: </para> +<screen +><prompt +>%</prompt +> <userinput +><command +>artsdsp</command +> <option +>esd</option +></userinput +> +</screen> +<para +>Nyere versioner af aRts ( +>= 1.2.0) kan også bruge Enlightened Sound Daemon i stedet for direkte adgang til lydkortet. På kommandolinjen kan du bruge flaget -a, på følgende måde </para> +<screen +><prompt +>%</prompt +> <userinput +><command +>artsd</command +> <option +>-a esd</option +></userinput +> +</screen> +<para +>til at få understøttelse af ESD. I stedet for, i KDE, kan du bruge kontrolcentret til at indstille artsd til at bruge ESD, via Lyd -> Lydserver -> Lyd I/O. </para> +</answer> +</qandaentry> + +</qandaset> + +<qandaset id="faq-latency"> +<title +>Latenstid</title> + +<qandaentry> +<question> +<para +>Ind imellem hører jeg korte pauser når jeg lytter til musik. Er dette en fejl? </para> +</question> +<answer> +<para +>Dette er formodentlig ikke en fejl, men forårsages af det faktum at &Linux; kernen ikke er særlig god til realtidsskemalægning. Der er situationer hvor &arts; ikke kan følge med i afspilningen. Du kan dog aktivere realtidsrettigheder (via kontrolcentret), og bruge en stor latenstidsindstilling (såsom <guilabel +>250 ms</guilabel +> eller <guilabel +>så stor som muligt</guilabel +>), hvilket bør forbedre situationen. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Hvad er effekten af svarstidsindstillingen? </para> +</question> +<answer> +<para +>Hjælpeteksten for denne indstilling i kontrolcentret kan være forvirrende. En lavere værdi betyder at &arts; reagerer hurtigere på ydre begivenheder (dvs. tiden det tager mellem et vindue lukkes og lyden afspilles af &artsd;). Den kommer også til at bruge flere <acronym +>CPU</acronym +>-ressourcer og det vil være mere sandsynligt med pauser i lyden.</para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Er der noget andet jeg kan gøre for at undgå pauser? </para> +</question> +<answer> +<para +>For brugere af <acronym +>IDE</acronym +>-enheder, kan man bruge kommandoen <command +>hdparm</command +> til at indstille din <acronym +>IDE</acronym +>-enhed til at bruge <acronym +>DMA</acronym +>-tilstand. Et advarselsord: Dette virker ikke med alle slags hardware, og kan forårsage at man skal lave en hardware-nulstilling, eller i sjældne tilfælde, tab af data. Læs dokumentationen for kommandoen <command +>hdparm</command +> for flere detaljer. Jeg har brugt følgende kommando med heldigt resultat: </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 +>Du skal køre dette efter hver boot, så måske vil du tilføje det i et opstartsscript for systemet (hvordan man gør dette er specifikt for hver distribution, på Debian &Linux; tilføjes det oftest i <filename +>/etc/rc.boot</filename +>). </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Realtidsprioritet synes ikke at have nogen virkning for mig? </para> +</question> +<answer> +<para +>Kontrollér at artswrapper virkelig er installeret suid <systemitem class="username" +>root</systemitem +>, som det er meningen at den skal være. Mange distributioner (for eksempel SuSE7.x) gør ikke dette. Du kan kontrollere det med: ls -l $(which artswrapper). Godt: <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 +> Dårligt: <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 +> Hvis du ikke har s'et med, kan du få det med: <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 +>Hvis du gør &artswrapper; SUID <systemitem class="username" +>root</systemitem +>, kommer det formodentlig til at forbedre kvaliteten på lydafgivelsen ved at reducere ophold i musikken. Dog øger det også risikoen for at en fejl i koden, eller en bruger med lyst til at skade kan få maskinen til at bryde sammen eller skade på anden måde. Desuden, at prioritere høj lydkvalitet på flerbrugermaskiner kan forårsage forværret ydelse for brugere som forsøger at bruge maskinen på en <quote +>produktiv</quote +> måde.</para> + +</answer> +</qandaentry> + + +<qandaentry> +<question> +<para +>Hvorfor tager &artsd; så meget <acronym +>CPU</acronym +>-tid? </para> +</question> +<answer> +<para +>Kontrollér dine svarstidsindstillinger. Desuden er den nuværende version ikke egentlig optimeret. Dette vil blive bedre, og indtil da kan det ikke rigtigt forudsiges hvor hurtig &artsd; kan eller ikke kan være. </para> +</answer> +</qandaentry> +</qandaset> + +<qandaset id="faq-network"> +<title +>Netværkstransparens</title> + +<qandaentry> +<question> +<para +>Hvad skal jeg gøre for at få netværkstransparens? </para> +</question> +<answer> +<para +>Aktivér det i kontrolcentrets indstillinger for <guilabel +>Lydserver</guilabel +> (<guilabel +>Aktivér sikkerheds- og referenceinformation for X11-serveren</guilabel +> og <guilabel +>Aktivér netværkstransparens</guilabel +>). Kopiér derefter din <filename +>.mcoprc</filename +>-fil til alle maskiner som du vil bruge netværkstransparensen fra. Log på igen. Sørg for at værtsmaskinerne som skal samarbejde kender hinandens navne (dvs. de har navne som kan opløses eller findes i <filename +>/etc/hosts</filename +>). </para> + +<para +>Dette skulle være alt du behøver at gøre. Hvis det ikke virker alligevel, følger nogen yderligere detaljer. &arts; lydserverprocessen &artsd; skal kun køres på en værtsmaskine, den med lydkortet hvor lyden skal afspilles. Den kan startes automatisk ved indlogning til &kde; (hvis du angiver det i kontrolcentret), eller manuelt med noget i retning af: </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 +>Flaget <option +>-n</option +> angiver netværkstransparens, mens de øvrige indstiller latenstider. </para> + +<para +>Din <filename +>.mcoprc</filename +>-fil skal indeholde denne linje: </para> + +<screen +><userinput +>GlobalComm=Arts::X11GlobalComm</userinput +> +</screen> + +<para +>for alle maskiner som er involverede, for at netværkstransparens skal virke. Det er dette som aktiveres af indstillingen <guilabel +>Aktivér sikkerheds- og referenceinformation over X11-serveren</guilabel +> i kontrolcentret. </para> + +<para +>Til sidst, i alle &kde;-versioner i 2.0.x serien, er der en fejl som viser sig hvis du ikke har et domænenavn indstillet. Klienter for &artsd; forsøger at finde en forbindelse via kombinationen af <systemitem class="systemname" +><replaceable +>værtsmaskinenavn</replaceable +>.<replaceable +>domænenavn</replaceable +></systemitem +>. Hvis domænenavnet er tomt, forsøger de at forbinde til <systemitem class="systemname" +><replaceable +>værtsmaskinenavn</replaceable +></systemitem +>. (læg mærke til det ekstra punktum). At tilføje en post som ser sådan her ud i <filename +>/etc/hosts</filename +> (dvs. <userinput +>orion.</userinput +> hvis værtsmaskinenavnet er <systemitem class="systemname" +>orion</systemitem +>) gør at man undgår problemet. </para> +</answer> +</qandaentry> + + +<qandaentry> +<question> +<para +>Hvordan fejlretter jeg netværkstransparens hvis det ikke virker? </para> +</question> +<answer> +<para +>Hvis du har &kde;'s kildekode, gå til <filename class="directory" +>tdelibs/arts/examples</filename +>, og kør <userinput +><command +>make</command +> <option +>check</option +></userinput +> for at kompilere nogle programmer, inklusive <application +>referenceinfo</application +>. Kør derefter </para> + +<screen +><prompt +>%</prompt +> <userinput +><command +>./referenceinfo</command +> <option +>global:Arts_SimpleSoundServer</option +></userinput +> +</screen> + +<para +>Udskriften angiver værtsmaskinenavnet og porten som bruges af &arts;. For eksempel, <computeroutput +>tcp:orion:1698</computeroutput +> ville betyde at alle klienter som forsøger at bruge netværkstransparens skal vide hvordan værtsmaskinen <systemitem class="systemname" +>orion</systemitem +> kan nås. </para> +</answer> +</qandaentry> + +</qandaset> + +<qandaset id="faq-hardware-specific"> +<title +>Hardware-specifikke spørgsmål</title> + +<qandaentry> +<question> +<para +>Hvilken hardware virker artsd ikke godt sammen med? </para> +</question> +<answer> +<para +>Det virker som om der er nogle få Linux-drivere som ikke virker godt sammen med aRts for visse udgaver af kernen. Læs først denne liste inden du rapporterer en fejl. Hvis du finder at informationen i listen ikke er fuldstændig, så tøv venligst ikke med at fortælle os om det. <informaltable +> <tgroup cols="4"> +<thead> +<row> +<entry +>Linux-driver/lydkort</entry> +<entry +>Virker ikke med</entry> +<entry +>Virker med</entry> +<entry +>Bemærkninger</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, kommerciel OSS-driver, alsa-0.5.12a med OSS-emulering</entry> +<entry +>driver forårsager for stor CPU-belastning (se nedenfor)</entry> +</row> + +<row> +<entry +>maestro 3/4-kredse</entry> +<entry +>2.4.9</entry> +<entry +>?</entry> +<entry +>driver forårsager ind imellem overbelastning af processoren (se nedenfor)</entry> +</row> + +<row> +<entry +>aureal8820, aureal8830-drivere fra sourceforge</entry> +<entry +>2.4.17</entry> +<entry +>?</entry> +<entry +>driver forårsager fejlmeddelelse / for meget CPU-belastning (se nedenfor)</entry> +</row> + +<row> +<entry +>OSS kommerciel 3.9.4g med Aureal Vortex</entry> +<entry +>?</entry> +<entry +>?</entry> +<entry +>systemet låses</entry> +</row> + +<row> +<entry +>ymfpci</entry> +<entry +>2.4.0, 2.4.12</entry> +<entry +>2.4.17</entry> +<entry +>driver forårsager fejlmeddelelse (se nedenfor)</entry> +</row> + + + +</tbody> +</tgroup> +</informaltable> +</para> +</answer> +</qandaentry> + + + +<qandaentry> +<question> +<para +>Hvorfor er der hardware-specifikke problemer, og hvordan ser jeg dem? </para> +</question> +<answer> +<para +>De almindelige problemer er at driveren ikke giver aRts tilstrækkelig eller tilstrækkeligt nøjagtig information om hvornår lyddata skal skrives. De fleste OSS-drivere giver rigtig information, men ikke alle. </para> +<para +>Du vil måske bemærke at visse andre programmer (såsom xmms) ikke behøver denne information, og derfor virker rigtigt til og med for din hardware. Men &arts; behøver denne information, så artsd vil måske ikke virke. Dette er stadigvæk en fejl i driveren, og ikke i &arts;. </para> +<para +>Der er to slags opførsel som artsd påviser når den køres med en fejlagtig driver. Enten forsøger den at sende ny data, men det lykkes egentlig aldrig, hvilket til slut fører til en for stor CPU-belastning, dette rapporteres, og at den afsluttes. Det andet problem er at artsd kan få forkert information om hvor meget data der skal skrives. Så <emphasis +>stopper</emphasis +> artsd med et fejlmeddelelse som: <screen +>artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int): +Assertion `len == can_write' failed. +Aborted +</screen> +</para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Hvad er forkert i driveren hvis jeg får problemet med for stor CPU-belastning? </para> +</question> +<answer> +<para +>Oftest bruger artsd kaldet select() for at holde styr på hvornår ny data skal skrives. Derefter bruger den kaldet ioctl(...GETOSPACE...), for at holde styr hvor meget data som skal skrives. Til sidst skriver den data. </para> +<para +>Et problem opstår hvis artsd enten altid vækkes, eller hvis der er meget lidt data at skrive. OSS-dokumentationen angiver at kaldet select() kun vækker en proces hvis der er mindst et fragment at skrive. Hvis artsd vækkes når der ikke er nogen, eller meget lidt, data at skrive, for eksempel en sampling, forsøger den at skrive små stumper med lyddata, hvilket kan blive meget kostbart, og til slut give for stor CPU-belastning. </para> +<para +>For at rette dette, skal driveren kun vække artsd hvis et helt fragment kan skrives. </para> +</answer> +</qandaentry> + +<qandaentry> +<question> +<para +>Hvad er forkert i driveren hvis jag får denne fejlmeddelelse? </para> +</question> +<answer> +<para +>Oftest bruger artsd kaldet select() for at holde styr på hvornår ny data skal skrives. Derefter bruger den kaldet ioctl(...GETOSPACE...), for at holde styr hvor meget data som skal skrives. Til sidst skriver den data. </para> +<para +>Hvis artsd ikke kan skrive så meget data som angives af kaldet ioctl, så stopper den med fejlmeddelelsen ovenfor. For at rette dette, skal driveren angive den rigtige størrelse på det ledige plads. </para> +</answer> +</qandaentry> +</qandaset> + +<qandaset id="faq-other"> +<title +>Andre problemer</title> + +<qandaentry> +<question> +<para +>Jeg kan ikke bruge &arts-builder;. Den bryder sammen når jeg kører et modul! </para> +</question> +<answer> +<para +>Den mest sandsynlige grund er at du bruger gamle strukturer eller moduler som ikke understøttes i &kde; 2 versionen. Desværre er dokumentationen på nettet for &arts;-0.3.4.1 som er helt forældet. Det oftest rapporterede sammenbrud er at hvis en struktur køres i &arts-builder; så fås fejlmeddelelsen <errorname +>[artsd] Synth_PLAY: lydsystemet bruges allerede.</errorname +> </para> + +<para +>Du skal bruge et Synth_AMAN_PLAY modul i stedet for Synth_PLAY så forsvinder problemet. Se også &arts-builder;'s hjælpefil (tryk på <keycap +>F1</keycap +> i &arts-builder;). </para> + +<para +>Nyere udgaver af &arts-builder; (&kde; 2.1 beta 1 og senere) levereres med et antal eksempler som du kan bruge. </para> +</answer> +</qandaentry> + +</qandaset> + +</chapter> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/future.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/future.docbook new file mode 100644 index 00000000000..f8d9923ad7d --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/future.docbook @@ -0,0 +1,399 @@ +<!-- <?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 +>Fremtidigt arbejde</title> + +<para +>Dette afsnit beskriver en del af det pågående arbejde med &arts;. Udviklingen går hurtigt fremad, så denne information kan være forældet. Du bør kontrollere listefilen TODO og arkiverne for <link linkend="mailing-lists" +>e-mail-listerne</link +> for at holde styr på hvilke nye funktioner der er planlagt. Deltag gerne i ny konstruktion og implementation. </para> + +<para +>Dette er et udkast som forsøger at give dig en oversigt over hvordan nye teknologier vil integreres i &arts;. Det dækker følgende: </para> + +<itemizedlist> +<listitem +><para +>Hvordan grænseflader virker.</para +></listitem> +<listitem +><para +>Afkodere - afkodning af mp3 eller wav-strømme til en form som gør at de kan bruges som data.</para +></listitem> +<listitem +><para +>Video.</para +></listitem> +<listitem +><para +>Trådning.</para +></listitem> +<listitem +><para +>Synkronisering.</para +></listitem> +<listitem +><para +>Dynamisk udvidelse/maskering.</para +></listitem> +<listitem +><para +>Dynamisk sammensætning.</para +></listitem> +<listitem +><para +>&GUI;</para +></listitem> +<listitem +><para +>&MIDI;</para +></listitem> +</itemizedlist> + +<para +>Dette er pågående arbejde. Det bør dog kunne give grundlaget hvis du vil kigge på ny teknologi i &arts;. Det bør give dig en almen idé om hvordan disse problemer vil blive angrebet. Korrigér gerne alt du ser her. </para> + +<para +>Ting som vil bruge &arts;-teknologi (så vær venlig og koordinér anstrengelserne): </para> + +<itemizedlist> +<listitem> +<para +><application +>K-telefon</application +> (tale via <acronym +>IP</acronym +>) </para> +</listitem> + +<listitem> +<para +>&noatun; (videoafspiller / lydafspiller) </para> +</listitem> + +<listitem> +<para +>&artscontrol; (styreprogram for lydserveren, og for målere) </para> +</listitem> + +<listitem> +<para +><application +>Brahms</application +> (musiksequencer) </para> +</listitem> + +<listitem> +<para +><application +>Kaiman</application +> (&kde;2 medieafspiller - kmedia2-kompliant) </para> +</listitem> + +<listitem> +<para +><application +>mpglib</application +>/<application +>kmpg</application +> (<acronym +>mpg</acronym +> lyd- og videoafspilningsteknologi) </para> +</listitem> + +<listitem> +<para +><application +>SDL</application +> (direkte medialag for spil, som endnu ikke er påbegyndt men som kan være behageligt) </para> +</listitem> + +<listitem> +<para +><application +>Elektriske ører</application +> (ophavsmanden kontaktede mig - status ukendt) </para> +</listitem> +</itemizedlist> + +<sect1 id="interfaces-how"> +<title +>Hvordan grænseflader virker</title> + +<!-- I think this is now obsolete and documented elsewhere ? --> + +<para +>&MCOP;-grænsefladen er grundlaget for &arts;-begrebet. De er det netværkstransparente ækvivalente til C++ klasser. Så snart det er muligt bør du indrette din konstruktion mod grænseflader. En grænseflade består af fire dele: </para> + +<itemizedlist> +<listitem +><para +>Synkrone strømme</para +></listitem> +<listitem +><para +>Asynkrone strømme</para +></listitem> +<listitem +><para +>Metoder</para +></listitem> +<listitem +><para +>Egenskaber</para +></listitem> +</itemizedlist> + +<para +>Disse kan blandes på en hvilken som helst måde du vil. Nye teknologier bør defineres ved hjælp af grænseflader. Læs afsnittene om asynkrone strømme og synkrone strømme, samt KMedia2-grænsefladen, som er gode eksempler på hvordan sådanne ting virker. </para> + +<para +>Grænseflader specificeres i <literal role="extension" +>.idl</literal +>-kode og køres gennem <command +>mcopidl</command +>-oversætteren. Man afleder <classname +><replaceable +>Grænsefladensnavn</replaceable +>_impl</classname +> klassen for at implementere dem, og bruger <function +>REGISTER_IMPLEMENTATION (Grænsefladensnavn_impl)</function +> til at indsætte en objektimplementering i &MCOP;'s objektsystem. </para> + +</sect1> + +<sect1 id="codecs"> +<title +>Codec'er, dataafkodning</title> + +<para +>Kmedia2-grænsefladen lader dig se bort fra at wav-filer, mp3-filer eller hvad som helst består af datastrømme. I stedet implementerer du kun metoder for at spille dem. </para> + +<para +>På den måde kan du skrive en bølgeformsladningsrutine på en måde så du kan spille bølgeformsfiler (som PlayObject), men ingen anden kan bruge din kode. </para> + +<para +>Asynkrone strømme ville være alternativet. Man definerer en grænseflade som tillader at datablokke sendes ind, og hentes ud. Dette ser sådan her ud i &MCOP;: </para> + +<programlisting +>interface Codec { + in async byte stream indata; + out async byte stream outdata; +}; +</programlisting> + + +<para +>Afkodere kan naturligvis også angive egenskaber for at udsende yderligere data, som formatinformation. </para> + +<programlisting +>interface ByteAudioCodec { + in async byte stream indata; + out async byte stream outdata; + readonly attribute samplingRate, bits, channels; +}; +</programlisting> + +<para +>Denne <interfacename +>ByteAudioCodec</interfacename +> kan for eksempel forbindes til et <interfacename +>ByteStreamToAudio</interfacename +>-objekt, for at oprette rigtigt flydende lyd. </para> + +<para +>Andre typer af afkodere kan naturligvis involvere at sende videodata direkte ud, som </para> + +<programlisting +>interface VideoCodec { + in async byte stream indata; + out video stream outdata; /* bemærk: videostrømme findes ikke endnu */ +}; +</programlisting> + +<para +>Sandsynligvis bør et afkodningsbegreb bruges i stedet for måden <quote +>du ved hvordan det spilles med det gør jeg ikke</quote +> som for eksempel <interfacename +>WavPlayObject</interfacename +> bruger for øjeblikket. Nogen skal dog sætte sig ned og eksperimentere lidt inden en programmeringsgrænseflade kan defineres. </para> + +</sect1> + +<sect1 id="video"> +<title +>Video</title> + +<para +>Min idé er at sørge for video som asynkrone strømme for en indbygget &MCOP;-datatype som indeholder billeder. Denne datatype er ikke lavet endnu. Ved at gøre dette, kan plugin som håndterer video kobles sammen på samme måde som lydi-plugin. </para> + +<para +>Der er nogle ting som det er vigtigt ikke at udelade: </para> + +<itemizedlist> +<listitem> +<para +>Der er <acronym +>RGB</acronym +> og <acronym +>YUV</acronym +> farverum. </para> +</listitem> +<listitem> +<para +>Formatet bør markeres i strømmen på en måde. </para> +</listitem> +<listitem> +<para +>Synkronisering er vigtig. </para> +</listitem> +</itemizedlist> + +<para +>Min idé er at lade muligheden for at ændre implementeringen af <classname +>VideoFrame</classname +>-klassen være åben, så den kan opbevare ting i et delt hukommelsessegment. Ved at gøre dette kan til og med videostrømme mellem forskellige processer blive mulige uden alt for store problemer. </para> + +<para +>For video er den almindelige situation dog at alle ting er i samme proces, fra afkodningen til visningen. </para> + +<para +>Jeg har lavet en prototypeimplementering af videostrømme, som kan hentes <ulink url="http://space.twc.de/~stefan/kde/download/video-quickdraw.tar.gz" +>herfra</ulink +>. Dette skal integreres med &MCOP; efter nogle eksperimenter. </para> + +<para +>En visningskomponent som understøtter XMITSHM (med <acronym +>RGB</acronym +> og <acronym +>YUV</acronym +>) bør der sørges for. Martin Vogt fortalte mig at han arbejder på en sådan. </para> + +</sect1> + +<sect1 id="threading"> +<title +>Trådning</title> + +<para +>For øjeblikket er &MCOP; helt og holdent en eneste tråd. For video kan vi måske ikke længere komme udenom tråde. O.k. Der er nogle ting som skal håndteres med forsigtighed: </para> + + +<itemizedlist> +<listitem +><para +>SmartWrappers - de er ikke trådsikre på grund af usikker referenceregning og lignende. </para> +</listitem> +<listitem> +<para +>Afsenderen / I/O - heller ikke trådsikre. </para> +</listitem> +</itemizedlist> + +<para +>Hvad jeg i alle tilfælde kan tænke mig er at gøre udvalgte moduler trådsikre, både for synkrone og asynkrone strømme. På denne måde kan man skemalægge signalstrømmen på to eller flere processorer, med et flowsystem som kender til tråde. Dette burde også hjælpe en hel del med lyd med multiprocessorer. </para> + +<para +>Hvordan det ville virke: </para> + + +<itemizedlist> +<listitem> +<para +>Flowsystemet bestemmer hvilke moduler der skal beregne hvad, dvs: </para> + <itemizedlist> + <listitem +><para +>videobilleder (med metoden process_indata)</para +></listitem> + <listitem +><para +>synkrone lydstrømme (calculateBlock)</para +></listitem> + <listitem +><para +>andre asynkrone strømme, i hovedsagen datastrømme</para +></listitem> + </itemizedlist> +</listitem> +<listitem> +<para +>Modulerne kan beregne disse ting i egne tråde. For lyd giver det mening at genbruge tråde (f.eks. håndtere den med fire tråde hvis der er fire processorer, også selvom 100 moduler kører). For video- og datakompression, kan det være bekvemmere at have en blokerende implementering i en egen tråd, som synkroniseres med resten af &MCOP; med flowsystemet. </para> +</listitem> + +<listitem> +<para +>Moduler må ikke bruge &MCOP;-funktioner (som fjernkaldes) mens trådede operationer er i gang. </para> +</listitem> +</itemizedlist> + +</sect1> + +<sect1 id="synchronization"> +<title +>Synkronisering</title> + +<para +>Video og &MIDI; (og lyd) kan kræve synkronisering. I grunden er dette tidsstempler. Idéen jeg har er at tilknytte tidsstempler til de asynkrone strømme, ved at tilføje et tidsstempel til hver pakke. Hvis man sender to videobilleder, gøres det helt enkelt som to pakker (de er store alligevel), så man kan have to forskellige tidsstempler. </para> + +<para +>Lyd skal have underforståede tidsstempler, eftersom det er synkront. </para> + +</sect1> + +<sect1 id="dynamic-composition"> +<title +>Dynamisk sammensætning</title> + +<para +>Det bør være muligt at sige: En effekt FX består af disse enkle moduler. FX bør se ud som en normal &MCOP;-modul (se maskering), men i virkeligheden bestå af andre moduler. </para> + +<para +>Dette kræves for &arts-builder;. </para> + +</sect1> + +<sect1 id="gui"> +<title +>&GUI;</title> + +<para +>Alle komponenter i den grafiske grænseflade vil være &MCOP;-moduler. De bør have egenskaber som størrelse, etiket, farve, ... En <acronym +>RAD</acronym +>-bygger (&arts-builder;) bør kunne sammensætte dem visuelt. </para> + +<para +>Den grafiske grænseflade bør det være muligt at gemme ved at gemme egenskaberne. </para> + +</sect1> + +<sect1 id="midi-stuff"> +<title +>&MIDI;</title> + +<para +>&MIDI;-tingene vil blive implementeret som asynkrone strømme. Der er to alternativer, en er at bruge normale &MCOP;-strukturer til at definere typerne og den anden er at introducere yderligere egne typer. </para> + +<para +>Jeg tror at normale strukturer vil slå til, dvs noget som: </para> + +<programlisting +>struct MidiEvent { + byte b1,b2,b3; + sequence<byte> sysex; +} +</programlisting> + +<para +>Asynkrone strømme bør understøtte egne strømningstyper. </para> + +</sect1> + +</chapter> + + diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/glossary.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/glossary.docbook new file mode 100644 index 00000000000..352e57f6654 --- /dev/null +++ b/tde-i18n-da/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. En lydkortsdriver for &Linux; som for øjeblikket ikke indgår som standard i kildekoden for kernen. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-arts"> +<glossterm +>&arts;</glossterm> +<glossdef> +<para +>Analog realtidssynthesizer. Navnet på den multimediaarkitektur/bibliotek/værktøjskasse som bruges af &kde;-projektet (bemærk de store bogstaver) </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-bsd"> +<glossterm +><acronym +>BSD</acronym +></glossterm> +<glossdef> +<para +>Berkeley Software Distribution. Refererer her til et af flere forskellige &UNIX;-kompatible operativsystemer som har deres oprindelse i <acronym +>BSD</acronym +> &UNIX;. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-corba"> +<glossterm +><acronym +>CORBA</acronym +></glossterm> +<glossdef> +<para +>Common Object Request Broker Architecture. En standard for at implementere objektorienteret fjernkørsel. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-cvs"> +<glossterm +><acronym +>CVS</acronym +></glossterm> +<glossdef> +<para +>Concurrent Versions System. Et konfigurationshåndteringssystem for programmel som bruges af mange programmelprojekter inklusive &kde; og &arts;. </para> +</glossdef> +</glossentry> + +<glossentry id="glos-fft"> +<glossterm +><acronym +>FFT</acronym +></glossterm> +<glossdef> +<para +>Fast Fourier Transform. En algoritme til at konvertere data fra tids- til frekvensdomæne, som ofte bruges i signalbehandling. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-full-duplex"> +<glossterm +>Full duplex</glossterm> +<glossdef> +<para +>Muligheden for et lydkort til samtidigt at indspille og afspille lyd. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-gpl"> +<glossterm +><acronym +>GPL</acronym +></glossterm> +<glossdef> +<para +><acronym +>GNU</acronym +> General Public License. En programmellicens som blev lavet af Free Software Foundation, som definerer betingelserne for at udgive frit programmel. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-gui"> +<glossterm +>&GUI;</glossterm> +<glossdef> +<para +>Grafisk brugergrænseflade </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-idl"> +<glossterm +><acronym +>IDL</acronym +></glossterm> +<glossdef> +<para +>Interface Definition Language. Et format uafhængigt af programmeringssprog til at definere grænseflader (metoder og data). </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-kde"> +<glossterm +>&kde;</glossterm> +<glossdef> +<para +>K-desktopmiljø. Et projekt for at udvikle et frit grafisk desktopmiljø for &UNIX;-kompatible systemer. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-lgpl"> +<glossterm +><acronym +>LGPL</acronym +></glossterm> +<glossdef> +<para +><acronym +>GNU</acronym +> Lesser General Public License. En programmellicens som blev lavet af Free Software Foundation, som definerer betingelserne for at udgive frit programmel, med endnu færre begrænsninger end <acronym +>GPL</acronym +> som ofte bruges til programmelbiblioteker. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-mcop"> +<glossterm +>&MCOP;</glossterm> +<glossdef> +<para +>Multimedia COmmunication Protocol. Protokollen som bruges til kommunikation mellem &arts; programmoduler, som har ligheder med <acronym +>CORBA</acronym +> men er enklere og optimeret for multimedia. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-midi"> +<glossterm +>&MIDI;</glossterm> +<glossdef> +<para +>Musical Instrument Digital Interface. En standardprotokol for kommunikation mellem elektroniske musikinstrumenter, angiver også ofte filformatet som bruges til at opbevare &MIDI;-kommandoer. </para> +</glossdef> +</glossentry> + +<glossentry id="gloss-oss"> +<glossterm +><acronym +>OSS</acronym +></glossterm> +<glossdef> +<para +>Open Sound System. Lyddriverne som indgår i &Linux;' kerne (sommetider kaldet <acronym +>OSS</acronym +>/Free) eller en kommerciel version som sælges af 4Front Technologies. </para> +</glossdef> +</glossentry> + +</glossary> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/gui.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/gui.docbook new file mode 100644 index 00000000000..b769c161b6b --- /dev/null +++ b/tde-i18n-da/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-da/docs/tdemultimedia/artsbuilder/helping.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/helping.docbook new file mode 100644 index 00000000000..629b9c497d0 --- /dev/null +++ b/tde-i18n-da/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 +>Hjælp til med &arts;</title> + +<sect1 id="how-to-help"> +<title +>Hvordan du kan hjælpe til</title> + +<para +>&arts;-projektet behøver hjælp fra udviklere for at at tilføje understøttelse for &arts; i eksisterende multimedieprogrammer, skrive nye multimedieprogrammer og forbedre &arts;' muligheder. Du behøver dog ikke være en udvikler for at bidrage. Vi behøver også hjælp fra testere til at indsende fejlrapporter, oversættere til at oversætte programteksten og dokumentationen til andre sprog, grafikere til at oprette ikoner (især for <application +>artsbuilder</application +> moduler), musikere til at lave &arts;-moduleksempler, og forfattere til at skrive eller gennemse dokumentation. </para> +</sect1> + +<sect1 id="mailing-lists"> +<title +>E-mail-lister</title> + +<para +>De fleste udviklingsdiskussioner om &arts; finder sted via to e-mail-lister. Dette er stedet at diskutere nye funktioner og implementeringsidéer og at spørge efter hjælp med problemer. </para> + +<para +>&kde;'s multimedie e-mail-liste er til for generelle &kde; multimediespørgsmål inklusive &arts; samt multimedieprogrammer såsom &noatun; og &aktion;. Du kan abonnere fra netsiden på <ulink url="http://www.kde.org/mailinglists.html" +> http://www.kde.org/mailinglists.html</ulink +> eller sende e-mail med emnet <userinput +>subscribe <replaceable +>din-e-mail-adresse</replaceable +></userinput +> til <email +>kde-multimedia-request@kde.org</email +>. Listen findes også arkiveret på <ulink url="http://lists.kde.org" +> http://lists.kde.org</ulink +>. </para> + +<para +>E-mail-listen for &arts; er til for spørgsmål som kun berører &arts;, inklusive brug af &arts; udenfor &kde;. For at abonnere, send e-mail til <email +>arts-request@space.twc.de</email +> med meddelelsesteksten <userinput +>subscribe <replaceable +>din-epostadresse</replaceable +></userinput +>. Listen arkiveres på <ulink url="http://space.twc.de/~stefan/arts-archive" +> http://space.twc.de/~stefan/arts-archive</ulink +>. </para> + +</sect1> + +<sect1 id="coding-standards"> +<title +>Kodningsstandarder</title> + +<para +>For at opnå en konsekvent læsning af al kildekode, er det vigtigt at holde kodningsstilen ens i hele &arts;' kildekode. Vær derfor rar og forsøg at skrive/formatere din kildekode i overensstemmelse med dette, også selvom du kun skriver et modul, eftersom det gør det enklere for forskellige personer at vedligeholde kildekodetræet, og lettere at kopiere dele af kildekoden fra en fil til en anden. </para> + +<variablelist> +<varlistentry> +<term +>Navngivning af medlemsfunktioner</term> +<listitem> +<para +>&Qt;/&Java;-stil. Dette betyder at store bogstaver bruges til at markere nye ord, og at det første bogstav altid er lille. Ingen understregninger. </para> +<para +>Dette betyder for eksempel:</para> + +<programlisting +>createStructureDesc() + updateWidget(); + start(); </programlisting> + +</listitem> +</varlistentry> + +<varlistentry> +<term +>Klassemedlemmer</term> +<listitem> +<para +>Klassemedlemmer har ikke store bogstaver, som for eksempel menubar eller button. </para> + +<para +>Når der er funktioner som bruges til adgang, skal standarden som bruges være ifølge &MCOP;-måden, dvs. hvis der er et "long" medlem <function +>foo</function +>, som ikke skal være synlig, så laves: </para> + +<programlisting +>foo(long new_value); + long foo(); </programlisting> + +<para +>funktioner for at hente eller sætte en værdi. I dette tilfælde, skal den rigtige værdi for <function +>foo</function +> opbevares i <returnvalue +>_foo</returnvalue +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Klassenavne</term> +<listitem> +<para +>Alle klasser skal have store bogstaver for hvert ord, hvilket betyder <classname +>ModuleView</classname +>, <classname +>SynthModule</classname +>. Alle klasser som hører til biblioteker skal bruge &arts;-navnerummet, såsom <classname +>Arts::Soundserver</classname +>. </para> +<para +>Implementeringer af &MCOP;-klasser skal døbes <classname +>Class_impl</classname +>, som for eksempel <classname +>SoundServer_impl</classname +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Parametre</term> +<listitem> +<para +>Parametre har altid små bogstaver. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Lokale variabler</term> +<listitem> +<para +>Lokale variabler har altid små bogstaver, og kan have navne såsom <varname +>i</varname +>, <varname +>p</varname +>, <varname +>x</varname +> osv. hvis det passer. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Tabulatorbredde (skiftbredde)</term> +<listitem> +<para +>Et tabulatortegn er lige så meget som fire blanke tegn. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>Mellemrum i udtryk</term> +<listitem> +<para +>Normalt behøver du ikke bruge mellemrum i udtryk. Du kan i alle tilfælde bruge dem mellem operatorer og deres operander. Hvis du skriver et mellemrum før en operator (f.eks. +), skal du også skrive et mellemrum efter operatoren. Den eneste undtagelse fra dette er udtryk som ligner lister (med ,), hvor du kun skal bruge et mellemrum efter ",", men ikke før. Det er også i orden at udelade mellemrum her. </para> +<para +>Følgende eksempel demonstrerer god brug af mellemrum: </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 +>Følgende eksempel demonstrerer hvordan man <emphasis +>ikke</emphasis +> skal bruge mellemrum. For funktionskald, efter if, while, for, switch og så videre, skrives intet mellemrum. </para> +<programlisting +>{ + // DÅRLIGT: Hvis du skriver en liste, skriv kun mellemrum efter "," + int a , b , c , d , e , f; + + // DÅRLIGT: ikke symmetrisk brug af mellemrum for = operatoren + a= 5; + + // DÅRLIGT: Hvis det anses at være en funktion, og ikke følges af et mellemrum + if (a == 5) { + } + + // DÅRLIGT: skriv ikke et mellemrum efter while + while (a--) + b++; + + // DÅRLIGT: Funktionsnavne følges ikke af et mellemrum + arts_debug ("%d\n", c); + + // DÅRLIGT: heller ikke medlemsnavne + Arts::Object o = Arts::Object::null (); +} +</programlisting> +</listitem> +</varlistentry> + + +<varlistentry> +<term +>Navngivning af kildekodefiler</term> +<listitem> +<para +>Kildekodefiler skal ikke have store bogstaver i navnet. De skal have samme navne som klassen hvis de implementerer en enkelt klasse. Deres filendelse skal være <literal role="extension" +>.cc</literal +> hvis de indeholder &Qt;- og grafikuafhængig kode, og <literal role="extension" +>.cpp</literal +> hvis de indeholder &Qt;- og grafikafhængig kode. Implementeringsfiler for grænseflader skal benævnes <filename +><replaceable +>foo</replaceable +>_impl</filename +>, hvis Foo er grænsefladens navn. </para> + +<para +>&IDL;-filer skal benævnes på en beskrivende måde med tanke på den samling grænseflader de indeholder, også helt med små bogstaver. I særdeleshed er det ikke godt at benævne en &IDL;-fil som klassen selv, eftersom .mcopclass-handleren og typeinfoposterne så vil kollidere. </para> +</listitem> +</varlistentry> +</variablelist> +</sect1> + +</chapter> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/index.cache.bz2 b/tde-i18n-da/docs/tdemultimedia/artsbuilder/index.cache.bz2 Binary files differnew file mode 100644 index 00000000000..edffad9020b --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/index.cache.bz2 diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/index.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/index.docbook new file mode 100644 index 00000000000..eb8ee5432e3 --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/index.docbook @@ -0,0 +1,397 @@ +<?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 % Danish "INCLUDE" +> <!-- change language only here --> + <!ENTITY % addindex "IGNORE"> +]> + +<book lang="&language;"> +<bookinfo> +<title +>&arts;-håndbogen</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> + +&erik.kjaer.pedersen.role; +</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 +>Denne håndbog beskriver &arts;, den analoge realtidssynthesizer.</para> + +</abstract> + +<keywordset> +<keyword +>aRts</keyword> +<keyword +>artsbuilder</keyword> +<keyword +>synthesizer</keyword> +<keyword +>multimedie</keyword> +<keyword +>struktur</keyword> +<keyword +>musik</keyword> +<keyword +>lyd</keyword> +<keyword +>KDE</keyword> +</keywordset> +</bookinfo> + +<chapter id="introduction"> +<title +>Indledning</title> + +<sect1 id="what-is-arts"> +<title +>Hvad er &arts;?</title> + +<para +>Den analoge realtidssynthesizer, eller &arts;, er et modulært system til at syntetisere lyd og musik på en digital computer. Med små byggeblokke, som kaldes moduler, kan brugeren let opbygge komplekse værktøjer til at behandle lyd. Moduler sørger for typiske funktioner såsom bølgeformsgeneratorer, filtre, lydeffekter, samt miksning og afspilning af digital lyd i forskellige filformater.</para> + +<para +>Lydserveren &artsd; blander lyd fra forskellige kilder i realtid, hvilket lader flere lydprogrammer få transparent delt adgang til lydkortet.</para> + +<para +>Ved at bruge &MCOP;, multimediakommunikationsprotokollen, kan multimedieprogrammer blive netværksgennemsigtige, sikkerhedsidentificerede, og virke på flere platforme med grænseflade som defineres på en sproguafhængig måde med &IDL;. Ældre programmer som ikke understøtter &arts; håndteres også. Som en central komponent i desktopmiljøet &kde; 2, sørger &arts; for grundlaget for &kde;'s arkitektur for multimedie, og vil støtte flere medietyper inklusive video i fremtiden. Ligesom &kde;, så kører &arts; på flere operativsystemer, inklusive &Linux; og BSD-varianter. Den kan også bruges uafhængig af &kde;.</para> + +</sect1> + +<sect1 id="using-this-manual"> +<title +>Brug af denne håndbog</title> + +<para +>Denne håndbog er beregnet til at give fuldstændig dokumentation for &arts; for brugere med forskellige kundskabsniveauer. Afhængig af om du er en hverdagsbruger af multimedieprogrammer som kører ved hjælp af &arts; eller en udvikler af multimedieprogrammer, kan du vælge at læse håndbogens afsnit i forskellig rækkefølge.</para> + +<para +>Vi foreslår at du først læser kapitlet <link linkend="installation" +>Hent og byg &arts;</link +> hvis du har brug for først at få &arts; installeret og kørbart. Hvis du allerede har et fungerende system, formodentlig installeret sammen med din operativsystemdistribution, kan du vælge at springe over dette afsnit.</para> + +<para +>Derefter bør du læse afsnittene i kapitlet <link linkend="arts-tools" +>&arts; værktøjer</link +>, især &artsd;, artscontrol;, &artsshell;, og &artsdsp;. Dette hjælper dig til at bruge &arts; på den mest effektive måde.</para> + +<para +>Hvis du er interesseret i at trænge yderligere ind i &arts;' funktion, så læs kapitlet om <link linkend="artsbuilder" +>&arts-builder;</link +> og gennemgå øvelsen. Dette bør give dig en forståelse for &arts;' kraftfulde muligheder og de moduler som er beregnet til at bruge uden at behøve at kunne programmere.</para> + +<para +>Hvis du vil lære dig mere om hvordan &arts; virker internt, enten for at udvikle multimedieprogrammer eller for at udvide selve &arts;, så læs nogle eller alle kapitlerne om <link linkend="arts-in-detail" +>&arts; i detalje</link +>. Dette bør give dig en forståelse for alle begreber som kræves for &arts;-programmeludvikling.</para> + +<para +>Hvis du er særligt interesseret i <acronym +>MIDI</acronym +>-funktionerne i &arts;, bør du læse kapitlet om <link linkend="midi" +>&MIDI;</link +>.</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 +>Hvis du vil udvikle multimedieprogrammer som bruger &arts;, beskrives de forskellige programmelgrænseflader (<acronym +>API</acronym +>) detaljeret i kapitlet <link linkend="arts-apis" +>&arts;-API</link +>.</para> + +<para +>Hvis du vil udvide &arts; ved at oprette nye moduler, læs kapitlet <link linkend="arts-modules" +>&arts;-moduler</link +>.</para> + +<para +>Hvis du ændrer et eksisterende program til at køre sammen med &arts;, så læs kapitlet <link linkend="porting" +>Overførsel af programmer til at passe sammen med &arts;</link +>.</para> + +<para +>Du kan også finde ud af hvordan du kan hjælpe med og bidrage til &arts;-projektet i kapitlet <link linkend="contributing" +>Bidrag til &arts;</link +>, læs om kommende udvikling af &arts; i kapitlet <link linkend="future-work" +>Fremtidigt arbejde</link +>, og finde link til mere information i afsnittet <link linkend="references" +>Referencer</link +>.</para> + +<para +>Vi har også afrundet håndbogen med en del yderligere materiale, inklusive <link linkend="faq" +>svar på almindelige spørgsmål</link +>, en <link linkend="contributors" +>liste over bidragydere</link +>, detaljer om &arts; <link linkend="copyright-and-licenses" +>ophavsret og licenser</link +>, og en del baggrundsmateriale om <link linkend="intro-digital-audio" +>digitallyd</link +> og <link linkend="midi-introduction" +>&MIDI;</link +>. En <link linkend="glossary" +>ordforklaring</link +> indgår også.</para> + +<note> +<para +>Denne håndbog er stadigvæk i stor udstrækning ufærdig. Du må gerne bidrage med at skrive dele af den, men hvis du vil gøre dette, så kontakt først Jeff Tranter <email +>tranter@kde.org</email +> eller Stefan Westerfeld <email +>stefan@space.twc.de</email +> for at undgå dobbeltarbejde. </para> +</note> + +</sect1> + +<sect1 id="history"> +<title +>Historien</title> + +<para +>Mod slutningen af 1997 begyndte Stefan Westerfeld at arbejde med et modulært realtidssystem for lydsyntese. Koden kørtes oprindeligt på et PowerPC-system med &AIX;. Den første implementering var meget enkel, men understøttede et flow-system med fuldstændig funktion som kunne gøre sådanne ting som at afspille MP3-filer og sende data gennem lydeffektmoduler. </para> + + +<para +>Næste skridt var at implementere en grafisk grænseflade, så moduler kunne manipuleres grafisk. Stefan havde en del god erfaring med at bruge &kde;, så derfor valgtes &kde; som den grafiske værktøjskasse, (med viden om at det kunne blive nødvendigt at lave en version med GNOME/Gtk+ også) og dette gjorde at &Linux; senere valgtes som den hovedsagelige udviklingsplatform. Projektet, som oprindeligt hed <application +>ksynth</application +>, omdøbtes til &arts; og udviklingstakten øgedes. På dette tidspunkt var projektet næsten komplet, med en <acronym +>CORBA</acronym +>-baseret protokol, dusinvis af moduler, et grafisk modulredigeringsværktøj, C og C++ grænseflade, dokumentation, værktøj og en e-mail-liste og netside med en lille gruppe udviklere. Projektet var kommet et godt stykke af vejen efter kun noget mere end et års udvikling.</para> + +<para +>Da &kde;-gruppen begyndte at planlægge for &kde; 2.0, blev det klart at &kde; behøvede en kraftfuldere infrastruktur for lyd og andre medietyper. Beslutningen blev taget at tilrette &arts;, eftersom det var et skridt i den rigtige retning med en gennemprøvet arkitektur. En ny stor udviklingsanstrengelse gjordes for denne nye version af &arts;, frem for alt udskiftningen af <acronym +>CORBA</acronym +>-koden med et helt nyt undersystem, &MCOP;, optimeret for multimedie. Version 0.4 af &arts; indgik i udgave 2.0 af &kde;.</para> + +<para +>Arbejdet med &arts; fortsætter, med at forbedre ydelsen og tilføje nye funktioner. Bemærk selvom &arts; nu er en central komponent i &kde;, kan den bruges uden &kde;, og bruges også af programmer som går udenfor traditionel multimedie. Projektet har modtaget en vis interesse fra GNOME-gruppen, som åbner en mulighed for at det i fremtiden kan blive standardarkitekturen for multimedie på &UNIX; desktopsystemer.</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; Ophavsret og licens</title> + +<para +>&arts; programmel ophavsret 1998-2001 Stefan Westerfeld <email +>stefan@space.twc.de</email +></para> + +<para +><anchor id="contributors"/> Dokumentation ophavsret 1999-2001 Stefan Westerfeld <email +>stefan@space.twc.de</email +> og Jeff Tranter <email +>tranter@kde.org</email +>. </para> +&erik.kjaer.pedersen.credit; +&underFDL; <para +>Alle biblioteker som indgår i &arts; udgives under betingelseren i <acronym +>GNU</acronym +> Lesser General Public licensen. En overvældende majoritet af koden i &arts; findes i biblioteker, inklusive hele <acronym +>MCOP</acronym +> og ArtsFlow. Dette tillader at bibliotekerne bruges af programmer som ikke er fri eller åbne hvis det ønskes sådan. </para> + +<para +>Det er et fåtal af programmer (såsom <application +>artsd</application +>), som udgives under betingelseren i <acronym +>GNU</acronym +> General Public License. Eftersom der har været forskellige meninger om det er tilladt eller ej at linke <acronym +>GPL</acronym +>-programmer med &Qt;, har jeg også tilføjet en udtrykkelig anmærkning som tillader dette, som en tilføjelse til <acronym +>GPL</acronym +>: tilladelse gives også at til at linke dette program med &Qt;-biblioteket, hvor &Qt; behandles som et bibliotek som normalt følger med operativsystemets kerne, hvad enten dette er tilfældet eller ej.</para> + +</chapter> + +<appendix id="installation"> +<title +>Installering af &arts;</title> + +<para +>For at kunne bruge &arts; skal du naturligtvis have det installeret og køre det på systemet. Der er to metoder at opnå dette, som beskrives i de følgende afsnit. </para> + +<sect1 id="binary-install"> +<title +>Installér en færdigkompileret binær udgave</title> + +<para +>Den hurtigste og enkleste måde at få &arts; køreklar er at installere færdigkompilerede binære pakker for systemet. De fleste nyere &Linux;-distributioner indeholder &kde;, og hvis det er &kde; 2.0 eller senere er &arts; med. Hvis &kde; ikke følger med installationen, kan det findes tilgængeligt til download fra din operativsystemleverandør. Som et alternativ kan det findes tilgængeligt fra tredjepart. Sørg for at du bruger pakker som passer sammen med dit operativsystem. </para> + +<para +>En grundlæggende installation af &kde; indeholder lydserveren, som tillader de fleste programmer at afspille lyd. Hvis du vil have hele opsætningen med multimedieværktøj og programmer, vil du formodentlig skulle installere yderligere valgfrie pakke. </para> + +<para +>Bagdelen ved at bruge færdigkompilerede binære filer er at de måske ikke indeholder den nyeste version af &arts;. Dette er særlig sandsynligt hvis de er kommet på cd-rom, eftersom udviklingstakten for &arts; og &kde; er sådan at cd-rom udgaver oftest ikke kan følge med. Du kan også komme ud for at færdigkompilerede binære pakker ikke er tilgængelige, hvis du har en mindre almindelig arkitektur eller operativsystemdistribution, og du må derfor bruge den anden metoden. </para> + +</sect1> + +<sect1 id="source-install"> +<title +>Byg fra kildekode</title> + +<para +>Selv om det tager tid, er den mest fleksible måde at bygge &arts; selv at kompilere den fra kildekode. Dette sikrer dig at du har en version som er optimalt kompileret for din systemopsætning og lader dig bygge den nyeste version. </para> + +<para +>Her har du to valg, du kan enten installere den nyeste stabile version som indgår i &kde; eller du kan skaffe den nyeste (men måske ustabile) udgave direkte fra &kde;-projektets <acronym +>CVS</acronym +>-arkiv. De fleste brugere som ikke udvikler med &arts; bør bruge den stabile version. Du kan hente den fra <ulink url="ftp://ftp.kde.org" +>ftp://ftp.kde.org</ulink +> eller et af de mange spejle. Hvis du allerede udvikler aktivt med &arts; vil du formodentlig bruge <acronym +>CVS</acronym +>-versionen. Hvis du vil bruge aRts uden KDE, kan du hente en selvstændig udviklingsversion fra <ulink url="http://space.twc.de/~stefan/kde/arts-snapshot-doc.html" +> http://space.twc.de/~stefan/kde/arts-snapshot-doc.html</ulink +>. </para> + +<para +>Bemærk at hvis du bygger fra <acronym +>CVS</acronym +>, vil visse komponenter i &arts; (dvs. de grundlæggende centrale komponenter inklusive lydserveren) være i <acronym +>CVS</acronym +>-modulet tdelibs, mens yderligere komponenter (f.eks. <application +>artsbuilder</application +>) indgår i tdemultimedia. Dette vil muligvis blive ændret i fremtiden. Du kan også finde en version i modulet kmusic, det er den gamle version (før &kde; 2.0) som nu er forældet. </para> + +<para +>Kravene til at bygge &arts; er i hovedsagen de samme som for &kde;. Konfigurationsscripterne bør opdage systemindstillingerne og angive om nogle nødvendige komponenter mangler. Sørg for at du har en fungerende lyddriver-rutine på systemet (enten <acronym +>OSS</acronym +>/Free driver i kernen, <acronym +>OSS</acronym +>-driveren fra 4Front Technologies, eller en <acronym +>ALSA</acronym +>-driver med <acronym +>OSS</acronym +>-støtte). </para> + +<para +>Mere information om at hente og installere &kde; (inklusive &arts;) findes i <ulink url="http://www.kde.org/documentation/faq/index.html" +>&kde;'s &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-da/docs/tdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/mcop.docbook new file mode 100644 index 00000000000..916d8b5f301 --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/mcop.docbook @@ -0,0 +1,1972 @@ +<!-- <?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="mcop"> +<title +>&MCOP;: objektmodel og strømme</title> + +<sect1 id="mcop-overview"> + +<title +>Oversigt</title> + +<para +>&MCOP; er standarden som &arts; anvender til: </para> + +<itemizedlist> +<listitem> +<para +>Kommunikation mellem objekter. </para> +</listitem> + +<listitem> +<para +>Netværkstransparens. </para> +</listitem> + +<listitem> +<para +>Beskrivelse af objektgrænseflader. </para> +</listitem> + +<listitem> +<para +>Sproguafhængighed. </para> +</listitem> +</itemizedlist> + +<para +>En vigtig del af &MCOP; er <emphasis +>grænsefladesbeskrivelsessproget</emphasis +>, &IDL;, som bruges til at definere mange af &arts; programmeringsgrænseflader og andre grænseflader på en sproguafhængig måde. </para> + +<para +>For at bruge en &IDL;-grænseflade fra C++, kompileres den med &IDL; oversætteren til C++ kode. Når du implementerer en grænseflade, afleder du fra skabelonklassen som &IDL; oversætteren har oprettet. Når man bruger en grænseflade gør man det med en omliggende skal. På denne måde kan &MCOP; bruge en protokol hvis objektet du taler med ikke er lokalt - man får netværkstransparens. </para> + +<para +>I dette kapitel er emnet at beskrive de grundlæggende funktioner i objektmodellen som er resultatet af at bruge &MCOP;, protokollen, hvordan &MCOP; bruges med C++ (sprogbindning), og så videre. </para> + +</sect1> + +<sect1 id="interfaces"> + +<title +>Grænseflade og &IDL;</title> + +<para +>Meget af den service som varetages af &arts;, såsom modulerne og lydserveren defineres i form af <acronym +>grænseflader</acronym +>. Grænseflader specificeres i et programsprogsuafhængig format: &IDL;. </para> + +<para +>Dette tillader at mange af implementeringsdetaljerne såsom formatet på multimediadatastrømmene, netværkstransparens og programsprogsuafhængig skjules for specifikationen af grænsefladen. Et værktøj, &mcopidl;, oversætter grænsefladedefinitionen til et specifikt programmeringssprog (for øjeblikket understøttes kun C++). </para> + +<para +>Værktøjet laver en skeletklasse med al standardkode og grundlæggende funktionalitet. Man afleder fra denne klassen for at implementere de funktioner man vil have. </para> + +<para +>Det &IDL; som bruges af &arts; ligner det som bruges af <acronym +>CORBA</acronym +> og <acronym +>DCOM</acronym +>. </para> + +<para +>&IDL;-filer kan indholde: </para> + +<itemizedlist> +<listitem> +<para +>C-stil #include-direktiv for andre &IDL;-filer. </para> +</listitem> + +<listitem> +<para +>Definitioner af nummereringstyper og struct-typer, som i C/C++. </para> +</listitem> + +<listitem> +<para +>Definitioner af grænseflade. </para> +</listitem> +</itemizedlist> + +<para +>I &IDL; defineres grænseflade på en måde som minder meget om en C++ klasse eller C-struct, dog med visse begrænsninger. Som i C++, så kan grænseflader være underklasser til andre grænseflader med arv. Grænsefladedefinitioner kan indeholde tre ting: Strømme, egenskaber og metoder. </para> + +<sect2 id="streams"> + +<title +>Strømme</title> + +<para +>Strømme definerer multimediadata, en af de vigtigste komponenter i et modul. Strømme defineres med følgende format: </para> + +<para +>[ async ] in|out [ multi ] <replaceable +>typ</replaceable +> stream <replaceable +>navn</replaceable +> [ , <replaceable +>navn</replaceable +> ] ; </para> + +<para +>Strømme har en defineret retning i forhold til modulet, som angives af de nødvendige parametre in eller out. Typeargumentet definerer datatypen, som kan være en hvilken som helst af typerne for egenskaber som beskrives senere (ikke alle understøttes endnu). Mange moduler bruger strømtypen audio, som er et alias for float eftersom det er det interne dataformatet for lydstrømme. Flere strømme af samme type kan indgå i samme definition med navne adskilt med kommategn. </para> + +<para +>Strømme er normalt synkrone, hvilket betyder at de er kontinuerlige dataflows med en konstant hastighed, såsom <acronym +>PCM</acronym +>-lyd. Parameteren async angiver en asynkron strøm, som bruges til ikke-kontinuerlige datastrømme. Det almindeligste eksempel på en asynkron strøm er &MIDI;-meddelelser. </para> + +<para +>Nøgleordet multi, som kun er gyldigt for inddatastrømme, angiver at grænsefladen understøtter et variabelt antal indgange. Dette er nyttigt til at implementere enheder såsom en mixer som kan tage imod et hvilket som helst antal inddatastrømme. </para> + +</sect2> +<sect2 id="attributes"> + +<title +>Attributter</title> + +<para +>Attributter er data som hører sammen med en udgave af en grænseflade. De deklareres som medlemsvariabler i C++, og kan bruges af en hvilken som helst af de primitive typer boolean, byte, long, string, eller float. Du kan også bruge selvdefinerede struct- eller nummereringstyper samt sekvenser af variabel størrelse med syntaksen sekvens<type>. Attributter kan valgfrit markeres som skrivebeskyttede. </para> + +</sect2> +<sect2 id="methods"> + +<title +>Metoder</title> + +<para +>Som i C++, kan metoder defineres i grænseflader. Metodeparametrene er begrænsede til samme typer som attributterne. Nøgleordet oneway angiver en metode som returnerer umiddelbart og køres asynkront. </para> + +</sect2> + +<sect2 id="standardinterfaces"> + +<title +>Standardgrænseflader</title> + +<para +>Flere grænseflader for standardmoduler er allerede definerede for dig i &arts;, såsom <interfacename +>StereoEffect</interfacename +>, og <interfacename +>SimpleSoundServer</interfacename +>. </para> + +</sect2> + +<sect2 id="example"> +<title +>Eksempel</title> + +<para +>Et enkelt eksempel på et modul taget fra &arts; er modulet med konstant forsinkelse, som findes i filen <filename +>tdemultimedia/arts/modules/artsmodules.idl</filename +>. Grænsefladedefinitionen angives nedenfor: </para> + +<programlisting +>interface Synth_CDELAY : SynthModule { + attribute float time; + in audio stream invalue; + out audio stream outvalue; +}; +</programlisting> + +<para +>Modulet arver <interfacename +>SynthModule</interfacename +>. Den grænseflade, som findes i <filename +>artsflow.idl</filename +>, definerer alle standardmetoder som implementeres i alle syntesemoduler. </para> + +<para +>CDELAY-effekten forsinker en stereolydstrøm med tidsværdien som angives som en decimaltal parameter. Grænsefladedefinitionen har en attribut af typen float til at opbevare forsinkelsesværdien. Den definerer to inddata- og to uddatastrømme (typisk for stereoeffekter). Ingen metoder kræves ud over de arvede. </para> + +</sect2> + +</sect1> + +<sect1 id="more-about-streams"> +<title +>Mere om strømme</title> + +<para +>Dette afsnit dækker en del yderligere emneområder som hører sammen med strømme. </para> + +<sect2 id="stream-types"> +<title +>Strømtyper</title> + +<para +>Der er forskellige krav for hvordan et modul kan håndtere strømningen. For at illustrere dette, betragt følgende eksempel: </para> + +<itemizedlist> +<listitem> +<para +>Skalering af et signal med en faktor to. </para> +</listitem> + +<listitem> +<para +>Udfører frekvenskonvertering af samplinger. </para> +</listitem> + +<listitem> +<para +>Dekomprimering af et runlength-kodet signal. </para> +</listitem> + +<listitem> +<para +>Læs &MIDI;-begivenheder fra <filename class="devicefile" +>/dev/midi00</filename +> og indsæt dem i en strøm. </para> +</listitem +> +</itemizedlist> + +<para +>Det første tilfælde er det enkleste: når modulet modtager 200 inddatasamplinger producerer det 200 uddatasamplinger. Det producerer kun uddata når det får inddata. </para> + +<para +>Det andet tilfælde producerer forskellige antal uddatasamplinger når det får 200 inddatasamplinger. Det afhænger af hvilken konvertering som udføres, men antallet er kendt i forvejen. </para> + +<para +>Det tredje tilfælde er endnu værre. Fra begyndelsen kan man ikke engang gætte hvor meget data som laves af 200 inddata byte (formodentlig meget mere end 200 byte, men...). </para> + +<para +>Det sidste tilfælde er et modul som aktiveres af sig selv, og sommetider laver data. </para> + +<para +>I &arts;-0.3.4, håndteredes kun strømme af den første type, og de fleste ting virkede godt. Dette er formodentlig hvad du mest behøver når du skriver moduler som behandler lyd. Problemerne med de andre, mere komplekse slags strømme er, at de er svære at programmere, og at man for det meste ikke behøver funktionerne. Dette er grunden til at vi gør dette med to forskellige slags strømtyper: synkrone og asynkrone. </para> + +<para +>Synkrone strømme har følgende egenskaber: </para> + +<itemizedlist> +<listitem> +<para +>Moduler skal kunne beregne data af en hvilken som helst længde, givet tilstrækkelig meget inddata. </para> +</listitem> + +<listitem> +<para +>Alle strømme har samme samplingsrate. </para> +</listitem> + +<listitem> +<para +>Funktionen <function +>calculateBlock()</function +> kaldes når tilstrækkeligt med data er tilgængelig, og modulet kan stole på at pegerne angiver data. </para> +</listitem +> + +<listitem> +<para +>Der er ingen allokering eller afallokering der skal gøres. </para> +</listitem> +</itemizedlist> + +<para +>Asynkrone strømme, på den anden side, opfører sig sådan her: </para> + +<itemizedlist> +<listitem> +<para +>Moduler kan producere data ind imellem, eller med varierende samplingsfrekvens, eller kun hvis de får inddata fra en fil. De skal ikke følge reglen <quote +>skal kunne håndtere forespørgsler af en hvilken som helst størrelse</quote +>. </para> +</listitem> + +<listitem> +<para +>Asynkrone strømme for et modul kan have helt forskellige samplingsrater. </para> +</listitem> + +<listitem> +<para +>Udgående strømme: der er særlige funktioner til at allokere pakker, til at sende pakker - og en valgfri mekanisme til at spørge efter data som fortæller når mere data skal laves. </para> +</listitem> + +<listitem> +<para +>Indkommende strømme: et kald sendes når en ny pakke modtages. Man skal fortælle når man er færdig med at behandle al data i den pakke, og dette må ikke ske med det samme (man kan fortælle om det når som helst senere, og hvis alle har behandlet en pakke, bliver den frigjort/genbrugt). </para> +</listitem> +</itemizedlist> + +<para +>Når strømme deklareres, bruges nøgleordet <quote +>async</quote +> til at angive at strømmen skal være asynkron. Så antag for eksempel at du vil konvertere en asynkron strøm af byte til en synkron strøm af samplinger. Grænsefladen ville så kunne se sådan her ud: </para> + +<programlisting +>interface ByteStreamToAudio : SynthModule { + async in byte stream inddata; // den asynkrone inddatasampling + + out audio stream left,right; // de synkrone uddatasamplinger +}; +</programlisting> + +</sect2> + +<sect2 id="async-streams"> +<title +>Brug af asynkrone strømme</title> + +<para +>Antag at du har bestemt dig for at skrive et modul som laver asynkron lyd. Dens grænseflade kunne se sådan her ud: </para> + +<programlisting +>interface SomeModule : SynthModule +{ + async out byte stream outdata; +}; +</programlisting> + +<para +>Hvordan sender man data? Den første metode kaldes <quote +>trykleverance</quote +>. Med asynkrone strømme sender man data som pakker. Det betyder at individuelle pakker sendes som i eksemplet ovenfor. Den virkelige proces er: allokér en pakke, fyld den, send den. </para> + +<para +>Her følger det i form af kode. Først allokerer vi en pakke: </para> + +<programlisting +>DataPacket<mcopbyte> *packet = outdata.allocPacket(100); +</programlisting> + +<para +>Så fylder vi den: </para> + +<programlisting +>// typekonvertering så fgets får en (char *) peger +char *data = (char *)packet->contents; + +// som du ser, kan du krympe pakkestørrelsen efter allokeringen +// hvis du vil +if(fgets(data,100,stdin)) + packet->size = strlen(data); +else + packet->size = 0; +</programlisting> + +<para +>Nu sender vi den: </para> + +<programlisting +>packet->send(); +</programlisting> + +<para +>Dette er meget enkelt, men hvis vi vil sende pakker nøjagtigt så hurtigt som modtageren kan håndtere dem, behøves en anden måde, metoden med <quote +>trækleverance</quote +>. Man beder om at sende pakker så hurtigt som modtageren er klar til at behandle dem. Man begynder med en vis mængde pakker som sendes. Mens modtageren behandler pakke efter pakke, begynder man at fylde dem igen med friske data, og sende dem igen. </para> + +<para +>Du starter det ved at kalde setPull. For eksempel: </para> + +<programlisting +>outdata.setPull(8, 1024); +</programlisting> + +<para +>Dette betyder at du vil sende pakke via uddata. Du vil begynde med at sende 8 pakker på én gang, og når modtageren behandler nogle af dem, vil du fylde dem op igen. </para> + +<para +>Derefter behøver du at implementere en metode som fylder pakken, som kunne se sådan her ud: </para> + +<programlisting +>void request_outdata(DataPacket<mcopbyte> *packet) +{ + packet->size = 1024; // skal ikke være mere end 1024 + for(int i = 0;i < 1024; i++) + packet->contents[i] = (mcopbyte)'A'; + packet->send(); +} +</programlisting> + +<para +>Det er alt. Når du ikke har flere data, kan du begynde at sende pakker med størrelsen nul, som stopper trækleverancerne. </para> + +<para +>Bemærk at det er væsentligt at give metoden nøjagtigt navnet <methodname +>request_<replaceable +>strømnavn</replaceable +></methodname +>. </para> + +<para +>Vi beskrev netop at sende data. At modtage data er meget enklere. Antag at du har et enkelt filter, ToLower, som helt enkelt konverterer alle bogstaver til små: </para> + +<programlisting +>interface ToLower { + async in byte stream inddata; + async out byte stream uddata; +}; +</programlisting> + +<para +>Dette er virkeligt enkelt at implementere. Her er hele implementationen: </para> + +<programlisting +>class ToLower_impl : public ToLower_skel { +public: + void process_inddata(DataPacket<mcopbyte> *inpacket) + { + DataPacket<mcopbyte> *outpacket = ouddata.allocPacket(inpacket->size); + + // lav om til små bogstaver + 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 +>Igen er det væsentligt at give metoden navnet <methodname +>process_<replaceable +>strømnavn</replaceable +></methodname +>. </para> + +<para +>Som du kan se, så får du et kald til en funktion for hver pakke som ankommer (<function +>process_indata</function +> i vort tilfælde). Du skal kalde metoden <methodname +>processed()</methodname +> for en pakke for at angive at du har behandlet den. </para> + +<para +>Her er et implementeringstip: Hvis det tager lang tid at behandle data (dvs. hvis du skal vente på udskrift til lydkortet eller noget sådant), så kald ikke processed med det samme, men opbevar hele datapakken og kald kun processed når du virkelig har behandlet pakken. På denne måde, har afsenderne en chance for at vide hvor lang tid det virkelig tager at udføre arbejdet. </para> + +<para +>Eftersom synkronisering ikke er så behagelig med asynkrone strømme, skal man bruge synkrone strømme så ofte som muligt, og kun asynkrone hvis det er nødvendigt. </para> + +</sect2> + +<sect2 id="default-streams"> +<title +>Standardstrømme</title> + +<para +>Antag at du har to objekter, for eksempel en AudioProducer og en AudioConsumer. AudioProducer har en uddatastrøm og AudioConsumer har en inddatastrøm. Hver gang du vil forbinde dem, bruger du disse to strømme. Den første brug af defaulting er at lade dig oprette forbindelsen uden at angive portene i dette tilfælde. </para> + +<para +>Antag nu at de to objekter ovenfor kan håndtere stereo, og begge har en <quote +>venstre</quote +> og <quote +>højre</quote +> port. Du vil stadigvæk skulle kunne koble dem sammen lige så let som tidligere. Men hvordan kan forbindelsesystemet vide hvilken udgang som skal kobles til hvilken indgang? Det har ingen måde at koble strømmene rigtigt sammen. Defaulting bruges så til at angive flere strømme med en vis rækkefølge. På den måde, hvis du forbinder et objekt med to standard uddatastrømme til et andet med to standard inddatastrømme, behøver du ikke angive portene, og forbindelserne gøres rigtigt. </para> + +<para +>Dette er naturligvis ikke begrænset til stereo. Hvilket som helst antal strømme kan gøres standard hvis det behøves, og forbindelsesfunktionen kontrollerer at antallet af standarder for to objekter passer sammen (med de angivne retninger) hvis du ikke angiver portene som skal bruges. </para> + +<para +>Syntaksen er den følgende: I &IDL; kan du bruge nøgleordet default i strømdeklarationen, eller på en enkelt linje. For eksempel: </para> + +<programlisting +>interface TwoToOneMixer { + default in audio stream input1, input2; + out audio stream output; +}; +</programlisting> + +<para +>I dette eksempel kommer objektet til at forvente at dets to inddataporte skal forbindes som standard. Rækkefølgen er den som angives på linjen, så et objekt som dette: </para> + +<programlisting +>interface DualNoiseGenerator { + out audio stream bzzt, couic; + default couic, bzzt; +}; +</programlisting> + +<para +>laver automatisk en forbindelse fra <quote +>couic</quote +> til <quote +>input1</quote +>, og <quote +>bzzt</quote +> til <quote +>input2</quote +> Bemærk at eftersom der kun er én udgang for mikseren, kommer den til at være standard i dette tilfælde (se nedenfor). Syntaksen som bruges i støjgeneratoren er nyttig til for at angive en anden rækkefølge end i deklarationen, eller til kun at vælge nogle få porte som standard. Retningen på portene på denne linje slås op af &mcopidl;, så angiv dem ikke. Du kan til og med blande ind- og udporte på en sådan linje, kun rækkefølgen spiller en rolle. </para> + +<para +>Der er nogle regler som følges når arv bruges: </para> + +<itemizedlist> +<listitem> +<para +>Hvis en standardliste angives i &IDL; så skal den bruges. En forælders port kan også indgå i listen, hvad enten de var standard forælderen eller ej. </para> +</listitem> + +<listitem> +<para +>Ellers arves forældrenes standarder. Rækkefølgen er forælder1 forvalg1, forælder1 forvalg2..., forælder2 forvalg1... Hvis der er en fælles forfader som bruger to forældregrene, laves en sammenfletning som ligner <quote +>virtual public</quote +> ved standardens første plads i listen. </para> +</listitem> + +<listitem> +<para +>Hvis der stadigvæk ikke er nogen standard og en eneste strøm i en vis retning, så bruges den som standard for den retning. </para> +</listitem> +</itemizedlist> + +</sect2> + +</sect1> +<sect1 id="attribute-change-notify"> +<title +>Ændringsmeddelelser for attributter</title> + +<!-- TODO: This should be embedded better into the context - I mean: the + context should be written ;-). --> + +<para +>Ændringsmeddelelser for attributter er en måde at vide når en attribut ændres. De kan i en vis udstrækning sammenlignes med et &Qt;- eller Gtk-signal eller slot. Hvis du for eksempel har et grafisk element, en skyder, som indstiller et tal mellem 0 og 100, har du oftest et objekt som gør noget med tallet (det kan for eksempel kontrollere lydstyrken på et lydsignal). Så vil du gerne at så snart skyderen flyttes skal objektet som indsteller lydstyrken underrettes. En forbindelse mellem en sender og modtagar. </para> + +<para +>&MCOP; håndterer dette ved at kunne give meddelelser når attributter ændres. Alt som deklareres som <quote +>attribute</quote +> i &IDL; kan afgive sådanne ændringsmeddelelser, og skal gøre det, nårsomhelst de ændres. Alt som deklareres som <quote +>attribute</quote +> kan også modtage sådanne ændringsmeddelelser. Så hvis du for eksempel har to &IDL;-grænseflader såsom disse her: </para> + +<programlisting +>interface Slider { + attribute long min,max; + attribute long position; + }; + interface VolumeControl : Arts::StereoEffect { + attribute long volume; // 0..100 + }; +</programlisting> + +<para +>kan du forbinde dem med ændringsmeddelelser. Det virker med det normale flydesystems forbindelsesoperation. I dette tilfælde, ser C++ koden som forbinder de to objekter sådan her ud </para> + +<programlisting +>#include <connect.h> +using namespace Arts; +[...] +connect(slider,"position_changed",volumeControl,"volume"); +</programlisting> + +<para +>Som du kan se, tilbyder hver egenskab to forskellige strømme, en for at sende ændringsmeddelelser, som hedder <function +><replaceable +>attributnavn</replaceable +>_changed</function +>, og en til at modtage ændringsmeddelelser, som hedder <function +>attributnavn</function +>. </para> + +<para +>Det er vigtigt at vide at ændringsmeddelelser og asynkrone strømme passer sammen. De er også netværkstransparente. Så du kan forbinde en flyttelsesegenskabs ændringsmeddelelse for en grafisk komponent til en asynkron strøm for en syntesemodul som kører på en anden maskine. Dette betyder naturligvis også at ændringsmeddelelser <emphasis +>ikke er synkrone</emphasis +>, hvilket betyder at det kan tage tid inden de virkelig modtages efter at du har sendt dem. </para> + +<sect2 id="sending-change-notifications"> + +<title +>Send ændringsmeddelelser</title> + +<para +>Når du implementerer objekter som har egenskaber, skal du sende ændringsmeddelelser så snart en egenskab ændres. Koden til at gøre dette ser sådan her ud: </para> + +<programlisting +>void KPoti_impl::value(float newValue) + { + if(newValue != _value) + { + _value = newValue; + value_changed(newValue); // <- send ændringsmeddelelse + } + } +</programlisting> + +<para +>Det anbefales varmt at bruge kode som denne for alle objekter som du implementerer, så ændringsmeddelelser kan bruges af andre. Du bør dog undgå at sende meddelelser for ofte, så hvis du laver signalbehandling er det formodentlig bedst at holde styr på hvornår du sendte din seneste meddelelse, så du ikke sender en for hver sampling. </para> + +</sect2> + +<sect2 id="change-notifications-apps"> +<title +>Anvendelser af ændringsmeddelelser</title> + +<para +>Det vil være særligt nyttigt at bruge ændringsmeddelelser sammen med målere (objekter som for eksempel visualiserer lyddata), grafiske grænseflader, kontrolelementer og monitorer. Kode som bruger dette findes i <filename class="directory" +>tdelibs/arts/tests</filename +>, og i den eksperimentelle artsgui-implementation, som du finder i <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 +>Filen <literal role="extension" +>.mcoprc</literal +></title> + +<para +>Filen <literal role="extension" +>.mcoprc</literal +> (i hver brugers hjemmemappe) kan bruges til at indstille &MCOP; på nogle måder. For øjeblikket er følgende muligt: </para> + +<variablelist> + +<varlistentry> +<term +>GlobalComm</term> +<listitem> +<para +>Navnet på en grænseflade som skal bruges til global kommunikation. Global kommunikation bruges til at finde andre objekter og hente den hemmelige cookie. Alle &MCOP; klienter/servere som skal kunne kommunikere med hinanden skal have et GlobalComm-objekt for at kunne dele information. For øjeblikket er de mulige værdier <quote +>Arts::TmpGlobalComm</quote +> for at kommunikere via mappen <filename class="directory" +>/tmp/mcop-<replaceable +>brugernavn</replaceable +></filename +> (som kun virker på den lokale maskine) og <quote +>Arts::X11GlobalComm</quote +> for at kommunikere via rootvinduesegenskaberne på X11-serveren. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>TraderPath</term> + +<listitem> +<para +>Angiver hvor handlerinformation skal findes. Du kan angive mere end en mappe her, og adskille dem med kommategn. </para> +</listitem> + +</varlistentry> + +<varlistentry> +<term +>ExtensionPath</term> + +<listitem> +<para +>Angiver fra hvilke mapper udvidelser (i form af delte biblioteker) indlæses. Flere værdier kan adskilles med kommategn. </para> +</listitem> + +</varlistentry> +</variablelist> + +<para +>Et eksempel som bruger alt det ovenstående er: </para> + +<programlisting +># $HOME/.mcoprc file +GlobalComm=Arts::X11GlobalComm + +# hvis du er udvikler kan det være bekvemt at tilføje et mappe i din +# hjemmemappe til TraderPath/ExtensionPath søgestierne for at kunne tilføje +# til komponenter uden at installere dem +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 +>-brugere</title> + +<para +>Hvis du har brugt <acronym +>CORBA</acronym +> tidligere, vil du kunne mærke at &MCOP; er meget lig. I virkeligheden så brugte &arts; <acronym +>CORBA</acronym +> inden version 0.4. </para> + +<para +>Den grundlæggende idé med <acronym +>CORBA</acronym +> er den samme: man implementerer objekter (komponenter). Ved at bruge funktionerne i &MCOP; er objekter ikke kun tilgængelige som normale klasser fra samme proces (via standard C++ teknikker), men de er også transparent tilgængelige for en fjernserver. For at dette skal virke, er det første du skal gøre at specificere grænsefladen for dine objekter i en &IDL;-fil, præcis som for <acronym +>CORBA</acronym +>-&IDL;. Der er kun et fåtal af forskelle. </para> + +<sect2 id="corba-missing"> +<title +><acronym +>CORBA</acronym +>-funktioner som mangles i &MCOP;</title> + +<para +>I &MCOP; er der ingen <quote +>in</quote +> og <quote +>out</quote +> parametre for metodekald. Parametre er altid indgående, og returværdien er altid udgående, hvilket betyder at grænsefladen: </para> + +<programlisting +>// CORBA idl +interface Account { + void deposit( in long amount ); + void withdraw( in long amount ); + long balance(); +}; +</programlisting> + +<para +>skrives som </para> + +<programlisting +>// MCOP idl +interface Account { + void deposit( long amount ); + void withdraw( long amount ); + long balance(); +}; +</programlisting> + +<para +>i &MCOP;. </para> + +<para +>Der er ingen støtte for undtagelser. &MCOP; har ikke undtagelser, den bruger noget andet til fejlhåndtering. </para> + +<para +>Der er ingen union-typer og ingen typedefinitioner. Jeg ved ikke om det er en virkelig svaghed, noget man desperat behøver for at overleve. </para> + +<para +>Der er ingen understøttelse for at sende grænseflader eller objektreferencer </para> + +</sect2> + +<sect2 id="corba-different"> +<title +><acronym +>CORBA</acronym +>-funktioner som er anderledes i &MCOP;</title> + +<para +>Du deklarerer sekvenser som <quote +>sequence<replaceable +>typ</replaceable +></quote +> i &MCOP;. Der er intet behov for en typedefinition. For eksempel, i stedet for: </para> + +<programlisting +>// CORBA idl +struct Line { + long x1,y1,x2,y2; +}; +typedef sequence<Line> LineSeq; +interface Plotter { + void draw(in LineSeq lines); +}; +</programlisting> + +<para +>ville du skrive </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;-funktioner som ikke findes i <acronym +>CORBA</acronym +></title> + +<para +>Du kan deklarere strømme, som senere behandles af &arts;' skelet. Strømme deklareres på en måde som ligner egenskaber. For eksempel: </para> + +<programlisting +>// MCOP idl +interface Synth_ADD : SynthModule { + in audio stream signal1,signal2; + out audio stream outvalue; +}; +</programlisting> + +<para +>Dette betyder at dit objekt vil acceptere to indkommende synkrone lydstrømme som kaldes signal1 og signal2. Synkron betyder at de er strømme som leverer x samplinger pr sekund (eller anden tid), så skemalæggeren altid garanterer at du får en balanceret mængde inddata (f.eks. 200 samplinger af signal1 er der og 200 samplinger af signal2 er der). Du garanterer at hvis dit objekt kaldes med disse 200 samplinger af signal1 + signal2, så kan det producere præcis 200 samplinger uddata. </para> + +</sect2> + +<sect2 id="mcop-binding"> +<title +>&MCOP;-bindingen til C++ sproget</title> + +<para +>Dette adskiller sig fra <acronym +>CORBA</acronym +> i hovedsagen hvad angår: </para> + +<itemizedlist> +<listitem> +<para +>Strenge bruger C++ <acronym +>STL</acronym +>-klassen <classname +>string</classname +>. Når de opbevares i sekvenser, opbevares de <quote +>enkelt</quote +>, hvilket betyder at de anses for at være en primitiv type. Derfor behøver de at blive kopieret. </para> +</listitem> + +<listitem> +<para +>long er enkle long (forventes at være 32 bit). </para> +</listitem> + +<listitem> +<para +>Sekvenser bruger C++ <acronym +>STL</acronym +>-klassen <classname +>vector</classname +>. </para> +</listitem> + +<listitem> +<para +>Strukturer afledes alle fra &MCOP; klassen <classname +>Type</classname +>, og genereres af &MCOP; &IDL;-oversætteren. Når de opbevares i sekvenser, opbevares de ikke <quote +>enkelt</quote +>, men som pegere, eftersom der ellers ville opstå for meget kopiering. </para> +</listitem> +</itemizedlist> +</sect2> + +<sect2 id="implementing-objects"> +<title +>Implementering af &MCOP;-objekter</title> + +<para +>Efter at have sendt dem gennem &IDL;-oversætteren, skal du aflede fra klassen <classname +>_skel</classname +>. Antag for eksempel at du har defineret grænsefladen sådan her: </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 +>Du sender det gennem &IDL;-oversætteren ved at kalde <userinput +><command +>mcopidl</command +> <parameter +>hello.idl</parameter +></userinput +>, som derefter laver <filename +>hello.cc</filename +> og <filename +>hello.h</filename +>. For at implementere dette, behøver du en C++ klasse som arver skelettet: </para> + +<programlisting +>// C++ deklarationsfil - indsæt hello.h et sted +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 +>Til sidst skal du implementere metoderne som almindelig C++. </para> + +<programlisting +>// C++ implementeringsfil + +// som du ser sendes strenge som konstante strengreferencer +void Hello_impl::hello(const string& s) +{ + printf("Hello '%s'!\n",s.c_str()); +} + +// når de er en returværdi sendes de som "normale" strenge +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 +>Når du har gjort dette, har du et objekt som kan kommunikere med &MCOP;. Opret kun et (med de normale C++ faciliteter til at oprette et objekt): </para> + +<programlisting +>Hello_impl server; +</programlisting> + +<para +>Og så snart du giver nogen referencen </para> + +<programlisting +>string reference = server._toString(); + printf("%s\n",reference.c_str()); +</programlisting> + +<para +>og gå til &MCOP;:s venteløkke </para> + +<programlisting +>Dispatcher::the()->run(); +</programlisting> + +<para +>har alle adgang til objektet med </para> + +<programlisting +>// denne kode kan køre hvorsomhelst - ikke nødvendigtvis i samme proces +// (den kan også køre på en anden maskine/arkitektur) + + Hello *h = Hello::_fromString([objektreferencen som blev udskrevet ovenifor]); +</programlisting> + +<para +>og kalde-metoder: </para> + +<programlisting +>if(h) + h->hello("test"); + else + printf("Adgang mislykkedes?\n"); +</programlisting> + +</sect2> +</sect1> + +<sect1 id="mcop-security"> +<title +>Sikkerhedshensyn for &MCOP;</title> + +<para +>Eftersom en &MCOP;-server lytter på en <acronym +>TCP</acronym +>-port, kan potentielt set alle (hvis du er forbundet til internettet) forsøge at forbinde til en &MCOP;-tjeneste. Derfor er det vigtigt at identificere klienter. &MCOP; bruger md5-auth protokollen. </para> + +<para +>Protokollen md5-auth gør følgende for at sikre at kun udvalgte (pålidelige) klienter kan forbinde til en server: </para> + +<itemizedlist> +<listitem> +<para +>Den antager at du kan give hver klient en hemmelig cookie. </para> +</listitem> + +<listitem> +<para +>Hver gang en klient forbindes, verificerer den at denne klient kender til den hemmelige cookie, uden virkelig at sende den (ikke engang på en form som nogen som lytter på netværkstrafik kunne finde ud af). </para> +</listitem> + +</itemizedlist> + +<para +>For at give hver klient den hemmelige cookie, putter &MCOP; den (normalt) i <filename class="directory" +>mcop</filename +> mappen (i <filename class="directory" +>/tmp/mcop-<envar +>USER</envar +>/secret-cookie</filename +>). Du kan naturligvis kopiere den til andre maskiner. Men hvis du gør det, så brug en sikker overførselsmekanisme, såsom <command +>scp</command +> (fra <application +>ssh</application +>). </para> + +<para +>Godkendelsen af klienter anvender følgende skridt: </para> + +<procedure> +<step> +<para +>[SERVER] opret en ny (tilfældig) cookie R </para> +</step> + +<step> +<para +>[SERVER] send den til klienten </para> +</step> + +<step> +<para +>[KLIENT] læs den "hemmelige cookie" S fra en fil </para> +</step> + +<step> +<para +>[KLIENT] bland cookierne R og S for at oprette en blandet cookie M med MD5-algoritmen </para> +</step> + +<step> +<para +>[KLIENT] send M til serveren </para> +</step> + +<step> +<para +>[SERVER] verificerer at blanding af R og S giver præcis samme cookie som cookien M som blev modtaget fra klienten. Hvis dette stemmer er godkendelsen lykkedes. </para> +</step> + +</procedure> + +<para +>Denne algoritme skulle være sikker, under forudsætning af at </para> + +<orderedlist> +<listitem> +<para +>De hemmelige og tilfældige cookier er <quote +>tilfældige nok</quote +> og </para> +</listitem> + +<listitem> +<para +>MD5-algoritmen ikke tillader at <quote +>originalteksten</quote +> kan afgøres, det vil sige den hemmelige cookie S og den tilfældige cookie R (som er kendt alligevel), fra den blandede cookie M. </para> +</listitem> +</orderedlist> + +<para +>&MCOP;-protokollen starter hver ny forbindelse med en godkendelsesprocess. Basalt ser den sådan her ud: </para> + +<procedure> + +<step> +<para +>Serveren sender meddelelsen ServerHello, som beskriver de kendte godkendelsesprotokoller. </para> +</step> + +<step> +<para +>Klienten sender meddelelsen ClientHello, som indeholder godkendelsesinformation. </para> +</step> + +<step> +<para +>Serveren sender meddelelsen AuthAccept. </para> +</step> +</procedure> + +<para +>For at se at sikkerheden virkelig virker, bør vi kigge på hvordan meddelelser behandles for ikke godkendte forbindelser: </para> + +<itemizedlist> +<listitem> +<para +>Inden godkendelsen er lykkedes, tager serveren ikke imod andre meddelelser fra forbindelsen. I stedet, hvis serveren for eksempel forventer sig meddelelsen <quote +>ClientHello</quote +>, og får meddelelsen mcopInvocation, så lukker den ned for forbindelsen. </para> +</listitem> + +<listitem> +<para +>Hvis klienten ikke sender en gyldig &MCOP;-meddelelse overhovedet (ingen magisk værdi &MCOP; i meddelelseshovedet) i godkendelsesfasen, uden noget andet, så lukkes der for forbindelsen. </para> +</listitem> + +<listitem> +<para +>Hvis klienten forsøger at sende en meget stor meddelelse (> 4096 byte) under godkendelsesfasen, kappes meddelelsesstørrelsen ned til 0 byte, hvilket gør at den ikke accepteres til godkendelse. Dette er der for at forhindre at ikke godkendte klienter sender f.eks. en 100 Mbyte meddelelse, som ville blive modtaget og kunne forårsage at serveren løber tør for hukommelse. </para> +</listitem> + +<listitem> +<para +>Hvis klienten sender en fejlagtig ClientHello meddelelse (en hvor afkodningen mislykkes), så lukkes der for forbindelsen. </para> +</listitem> + +<listitem> +<para +>Hvis klienten ikke sender noget i det hele taget, skal en tidsgrænse overskrides (endnu ikke implementeret). </para> +</listitem> +</itemizedlist> + +</sect1> + +<sect1 id="mcop-protocol"> +<title +>&MCOP; protokolspecifikation</title> + +<sect2 id="mcop-protocol-intro"> +<title +>Indledning</title> + +<para +>Den har begrebsmæssige ligheder med <acronym +>CORBA</acronym +>, men er beregnet til at kunne udvides på alle måder som kræves for multimediaoperationer i realtid. </para> + +<para +>Den sørger for en multimediaobjektmodel, som både kan bruges til kommunikation mellem komponenter i et adresserum (en proces), og mellem komponenter som findes i forskellige tråde, processer eller på forskellige værtsmaskiner. </para> + +<para +>Totalt set, vil den blive konstrueret til ekstremt høj ydelse (så alt skal optimeres for at være voldsomt hurtigt), passende for meget kommunikationsintensive multimedieprogrammer. At for eksempel sende video rundt er en af tilpasningerne for &MCOP;, hvor de fleste <acronym +>CORBA</acronym +>-implementationer ville gå i knæ. </para> + +<para +>Grænsefladedefinitionerne kan håndtere følgende selv: </para> + +<itemizedlist> +<listitem> +<para +>Kontinuerlige datastrømme (såsom lyddata). </para> +</listitem> + +<listitem> +<para +>Begivenhedsstrømme af data (såsom &MIDI;-begivenheder). </para> +</listitem> + +<listitem> +<para +>Rigtig referenceregning. </para> +</listitem> +</itemizedlist> + +<para +>og de vigtigste <acronym +>CORBA</acronym +>-kneb, såsom </para> + +<itemizedlist> +<listitem> +<para +>Synkrone metodekald. </para> +</listitem> + +<listitem> +<para +>Asynkrone metodekald. </para> +</listitem> + +<listitem> +<para +>Konstruere brugerdefinerede datatyper. </para> +</listitem> + +<listitem> +<para +>Multipel arv. </para> +</listitem> + +<listitem> +<para +>Sende objektreferencer. </para> +</listitem> +</itemizedlist> + +</sect2> + +<sect2 id="mcop-protocol-marshalling"> +<title +>&MCOP;'s meddelelseskodning</title> + +<para +>Konstruktionsmål/idéer: </para> + +<itemizedlist> + +<listitem> +<para +>Kodning skal være enkelt at implementere. </para> +</listitem> + +<listitem> +<para +>Afkodning kræver at modtageren véd hvilken type som skal afkodes. </para> +</listitem> + +<listitem> +<para +>Modtageren forventes at bruge al information, så mulighed for at hoppe over data findes kun i protokollen i det omfang at: </para> + +<itemizedlist> +<listitem> +<para +>Hvis man ved at en blok af data bliver modtaget, behøver man ikke kigge på hver del efter en slutmarkør. </para> +</listitem> + +<listitem> +<para +>Hvis man ved at en streng vil blive modtaget, behøver man ikke læse til en null-byte for at finde ud af dens længde ved afkodning, men, </para> +</listitem> + +<listitem> +<para +>Hvis man véd at en sekvens af strenge bliver modtaget skal man kigge på længden for hver af dem for at finde ud af slutningen af sekvensen, eftersom strenge har variabel længde. Men hvis strengene bruges til noget nyttigt, skal det gøres i alle tilfælde, så dette er ikke noget tab. </para> +</listitem> +</itemizedlist> + +</listitem> + +<listitem> +<para +>Så lidt ekstra omkostning som muligt. </para> +</listitem> +</itemizedlist> + +<!-- TODO: Make this a table --> + +<para +>Kodningen af de forskellige typer vises i tabellen nedenfor: </para> + +<informaltable> +<tgroup cols="3"> +<thead> +<row> +<entry +>Type</entry> +<entry +>Kodningsproces</entry> +<entry +>Resultat</entry> +</row> +</thead> + +<tbody> +<row> +<entry +><type +>void</type +></entry> +<entry +>typen <type +>void</type +> kodes ved at udelade den, så ingenting skrives til strømmen for den.</entry> +<entry +></entry> +</row> + +<row> +<entry +><type +>long</type +></entry> +<entry +>kodes som fire byte, med den mest signifikante først, så tallet 10001025 (som er 0x989a81) vil blive kodet som:</entry> +<entry +><literal +>0x00 0x98 0x9a 0x81</literal +></entry> +</row> + +<row> +<entry +><type +>nummereringstyper</type +></entry> +<entry +><para +>kodes som <type +>long</type +></para +></entry> +<entry +></entry> +</row> + +<row> +<entry +><type +>byte</type +></entry> +<entry +><para +>kodes som en enkelt byte, så 0x42 vil blive kodet som:</para +></entry> +<entry +><literal +>0x42</literal +></entry> +</row> + +<row> +<entry +><type +>streng</type +></entry> +<entry +><para +>kodes som en <type +>long</type +>, som indeholder længden på den efterfølgende streng, og derefter sekvensen af tegn. Strenge skal slutte med en null-byte (som indgår i længdeberegningen).</para> +<important> +<para +>inklusive den sidste 0 byte i længderegningen!</para> +</important> +<para +><quote +>hello</quote +> ville blive kodet som:</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 +>kodes som en byte, som indeholder 0 hvis <returnvalue +>false</returnvalue +> eller 1 hvis <returnvalue +>true</returnvalue +>, så at den booleske værdi <returnvalue +>true</returnvalue +> kodes som:</para +></entry> +<entry +><literal +>0x01</literal +></entry> +</row> + +<row> +<entry +><type +>float</type +></entry> +<entry +><para +>kodes med fire-byte IEEE754 repræsentationen, detaljeret dokumentation om hvordan IEEE fungerer findes her: <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 +> og her: <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 +>. Så værdien 2,15 ville blive kodet som:</para +></entry> +<entry +><literal +>0x9a 0x99 0x09 0x40</literal +></entry> +</row> + +<row> +<entry +><type +>struct</type +></entry> +<entry +><para +>En struktur kodes ved at kode dens indhold. Der kræves ingen yderligere præfiks eller suffiks, så strukturen </para> +<programlisting +>struct test { + string name; // som er "hello" + long value; // som er 10001025 (0x989a81) +}; +</programlisting> +<para +>ville blive kodet som:</para +></entry> +<entry> +<literallayout +>0x00 0x00 0x00 0x06 0x68 0x65 0x6c 0x6c +0x6f 0x00 0x00 0x98 0x9a 0x81 +</literallayout +></entry> +</row> + +<row> +<entry +><type +>sekvens</type +></entry> +<entry +><para +>En sekvens kodes ved at lave en liste over antallet af elementer som følger, og derefter kode elementerne en efter en.</para> +<para +>Så en sekvens med tre "long a", med a[0] = 0x12345678, a[1] = 0x01 og a[2] = 0x42 ville blive kodet som</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 +>Hvis du har brug for at henvise til en type, angives alle primitive typer med navnene som findes ovenfor. Strukturer og nummereringstyper får deres egne navne (som Header). Sekvenser benævnes som *<replaceable +>normal type</replaceable +>, så en sekvens af long er <quote +>*long</quote +> og en sekvens af Header struct'er er <quote +>*Header</quote +>. </para> + +</sect2> + +<sect2 id="mcop-protocol-messages"> +<title +>Meddelelser</title> + +<para +>Formatet på &MCOP;'s meddelelseshovede defineres af denne struktur: </para> + +<programlisting +>struct Header { + long magic; // værdien 0x4d434f50, som kodes som MCOP + long messageLength; + long messageType; +}; +</programlisting> + +<para +>De mulige meddelelsetyper er for øjeblikket </para> + +<programlisting +>mcopServerHello = 1 + mcopClientHello = 2 + mcopAuthAccept = 3 + mcopInvocation = 4 + mcopReturn = 5 + mcopOnewayInvocation = 6 +</programlisting> + +<para +>Lidt information om &MCOP;'s meddelelseshåndtering: </para> + + +<itemizedlist> +<listitem> +<para +>Hver meddelelse begynder med et hoved. </para> +</listitem> + +<listitem> +<para +>Visse meddelelsestyper skal ignoreres af serveren, indtil godkendelsen er færdig. </para> +</listitem> + +<listitem> +<para +>Efter at hovedet er modtaget, kan protokolhåndteringen (forbindelsen) tage imod meddelelsen i sin helhed, uden at kigge på indholdet. </para> +</listitem> +</itemizedlist> + +<para +>Meddelelseslængden i hovedet er naturligvis sommetider redundant, hvilket gør at metoden ikke altid er minimal med hensyn til antal byte. </para> + +<para +>Dette giver dog en enkel (og hurtig) implementation for behandling af meddelelser som ikke blokerer. Ved hjælp af hovedet kan meddelelser modtages af protokolhåndteringsklasser i baggrunden (uden blokering), hvis der er mange forbindelser til serveren kan alle behandles parallelt. Man behøver ikke kigge på meddelelsens indhold for at tage imod en meddelelse (og afgøre når man er klar), kun på hovedet, så koden for dette er ganske enkel. </para> + +<para +>Når en meddelelse er på plads, kan den afkodes og behandles i et enkelt skridt, uden at bryde sig om tilfælde hvor al data måske ikke er modtaget (eftersom meddelelseslængden garanterer at alt er på plads). </para> + +</sect2> + +<sect2 id="mcop-protocol-invocations"> +<title +>Kald</title> + +<para +>For at kalde en fjernmetode, skal man sende følgende struktur i en &MCOP;-meddelelse med messageType = 1 (mcopInvocation): </para> + +<programlisting +>struct Invocation { + long objectID; + long methodID; + long requestID; +}; +</programlisting> + +<para +>derefter sendes parametrene som en struktur, f.eks. hvis man kalder metoden "string concat(string s1, string s2)", sendes strukturen </para> + +<programlisting +>struct InvocationBody { + string s1; + string s2; +}; +</programlisting> + + +<para +>hvis metoden deklareredes som envejs, hvilket betyder asynkront uden returværdi, er det alt. Ellers får man en meddelelse som svar med messageType = 2 (mcopReturn). </para> + +<programlisting +>struct ReturnCode { + long requestID; + <resulttype> result; +}; +</programlisting> + + +<para +>hvor <resulttype> er typen for resultatet. Eftersom void-typer udelades ved kodning, kan man også kun angive requestID hvis man returnerer fra en void-metode. </para> + +<para +>Så vor "string concat(string s1, string s2)" ville give en returkode som </para> + +<programlisting +>struct ReturnCode { + long requestID; + string result; +}; +</programlisting> + +</sect2> + +<sect2 id="mcop-protocol-inspecting"> +<title +>Inspektér grænseflader</title> + +<para +>For at lave kald, skal man kende til metoderne som et objekt understøtter. For at gøre dette, er methodID 0, 1, 2 og 3 hårdkodede for visse funktioner. Det vil sige </para> + +<programlisting +>long _lookupMethod(MethodDef methodDef); // metode-id altid 0 +string _interfaceName(); // metod-id altid 1 +InterfaceDef _queryInterface(string name); // metodie-id altid 2 +TypeDef _queryType(string name); // metodie-id altid 3 +</programlisting> + +<para +>for at læse dette, behøver du naturligvis også </para> + +<programlisting +>struct MethodDef { + string methodName; + string type; + long flags; // nu sat til 0 (kræves for strømme) + sequence<ParamDef> signature; +}; + +struct ParamDef { + string name; + long typeCode; +}; +</programlisting> + +<para +>parameterfeltet indeholder typekomponenter som angiver typerne for parametrene. Typen for returkoden angives i typefeltet for MethodDef. </para> + +<para +>Hvis man skal være streng, er det kun metoderne <methodname +>_lookupMethod()</methodname +> og <methodname +>_interfaceName()</methodname +> som varierer fra objekt til objekt, mens <methodname +>_queryInterface()</methodname +> og <methodname +>_queryType()</methodname +> altid er ens. </para> + +<para +>Hvad er en sådan her methodID? Hvis man laver et &MCOP;-kald, forventes man at sende nummeret for metoden som kaldes. Årsagen til dette er at numre kan behandles meget hurtigere end strenge når en &MCOP;-forespørgsel køres. </para> + +<para +>Så hvordan skaffer man sig et sådan nummer? Hvis man kender til signaturen for metoden, dvs. en MethodDef som beskriver den (som indeholder navn, type, parameternavn, parametertyper og lignende), så kan man sende den til _lookupMethod for objektet hvor man vil kalde en metode. Eftersom _lookupMethod er hårdkodet til methodID 0, skulle det ikke være nogen problem at gøre dette. </para> + +<para +>Hvis man på den anden side ikke kender til metodens signatur, kan man finde hvilke metoder der understøttes ved at bruge _interfaceName, _queryInterface og _queryType. </para> +</sect2> + +<sect2 id="mcop-protocol-typedefs"> +<title +>Typedefinitioner</title> + +<para +>Brugerdefinerede datatyper beskrives med strukturen <structname +>TypeDef</structname +>: </para> + +<programlisting +>struct TypeComponent { + string type; + string name; +}; + +struct TypeDef { + string name; + + sequence<TypeComponent> contents; +}; +</programlisting> + +</sect2> +</sect1> + +<sect1 id="why-not-dcop"> +<title +>Hvorfor &arts; ikke bruger &DCOP;</title> + +<para +>Eftersom &kde; droppede <acronym +>CORBA</acronym +> fuldstændigt, og i stedet bruger &DCOP; overalt, opstår naturligvis spørgsmålet hvorfor ikke &arts; også gør det. Trods alt findes &DCOP;-understøttelse i <classname +>KApplication</classname +>, er godt vedligeholdt, forventes at integreres udmærket med libICE, og alt muligt andet. </para> + +<para +>Eftersom der (muligvis) vil være mange som spørger om det virkelig er nødvendigt at have &MCOP; foruden &DCOP;, så er svaret her. Misforstå mig ikke, jeg forsøger ikke at sige at <quote +>&DCOP; er dårlig</quote +>. Jeg forsøger kun at sige at <quote +>&DCOP; ikke er den rette løsning for &arts;</quote +> (mens det er en god løsning for andre ting). </para> + +<para +>Først skal man forstå nøjagtigt hvad &DCOP; blev skrevet for. Oprettet på to dage under mødet &kde;-TWO, var det hensigten at være så enkel som muligt, en virkelig <quote +>letvægts</quote +> kommunikationsprotokol. I særdeleshed udelod implementationen alt som kunne indebære kompleksitet, for eksempel et fuldstændigt begreb om hvordan datatyper skal kodes. </para> + +<para +>Selvom &DCOP; ikke bryder sig om visse ting (som hvordan man sender en streng på en netværkstransparent måde), skal dette gøres. Så alt som &DCOP; ikke gør overlades til &Qt; i &kde;-programmerne som bruger &DCOP; i dag. Dette er i hovedsagen typehåndtering (som bruger &Qt;'s serialiseringsoperator). </para> + +<para +>Så &DCOP; er en minimal protokol som gør det helt muligt for &kde;-programmer at sende enkle meddelelser såsom <quote +>åbn et vindue som peger på http://www.kde.org</quote +> eller <quote +>dine indstillinger er ændrede</quote +>. Inde i &arts; fokuseres imidlertid på andre ting. </para> + +<para +>Idéen er at små plugin i &arts; skal kommunikere med sådanne datastrukturer som <quote +>midi-begivenheder</quote +> og <quote +>sangpositionspegere</quote +> og <quote +>flydegrafer</quote +>. </para> + +<para +>Dette er komplekse datatyper, som skal sendes mellem forskellige objekter, og håndteres som strømme, eller parametre. &MCOP; sørger for et typebegreb til at definere komplekse datatyper ud fra enklere (ligesom struct'er og felter i C++). &DCOP; bryder sig ikke om typer i det hele taget, så dette problem skulle overlades til programmøren, såsom at skrive C++ klasser for typerne, og sikre sig at de kan serialisere på en rigtig måde (for eksempel understøttelse for &Qt;'s serialiseringsoperator). </para> + +<para +>Men på den måde ville de ikke være tilgængelige for noget andet end direkte kodning i C++. I særdeleshed ville man ikke kunne oprette et scriptsprog som ville kunne kende til alle typer som et plugin kan gøre tilgængelige, eftersom de ikke ville være selvbeskrivende. </para> + +<para +>Samme argument gælder også grænseflader i stor udstrækning. &DCOP;-objekter gør ikke deres forhold, arvhierarkier, osv. tilgængelige. Hvis man ville skrive en objektbladrer som ville vise <quote +>hvilke egenskaber har dette objekt</quote +>, ville det mislykkes. </para> + + +<para +>Selvom Matthias fortalte mig at man har en speciel funktion <quote +>functions</quote +> for hvert objekt som informerer om hvilke metoder som objektet understøtter, udelader dette ting såsom egenskaber, strømme og arvrelationer. </para> + +<para +>Dette gør at programmer som &arts-builder; ikke ville fungere overhovedet. Men husk, det var ikke meningen at &DCOP; skulle være en objektmodel (eftersom &Qt; allerede har en med <application +>moc</application +> og lignende), heller ikke være noget som <acronym +>CORBA</acronym +>, men sørge for kommunikation mellem programmer. </para> + +<para +>Årsagen til at &MCOP; overhovedet findes er at den skal virke godt med strømme mellem objekter. &arts; bruger mange små plugin, som forbindes med strømme. <acronym +>CORBA</acronym +>-versionen af &arts; var tvunget til at introducere en besværlig opdeling mellem <quote +>SynthModule-objekt</quote +>, som var de interne arbejdsmoduler som oprettede strømme, og <quote +><acronym +>CORBA</acronym +>-grænseflade</quote +>, som var noget eksternt. </para> + +<para +>Meget kode bekymrede sig om at opnå at vekselvirkningen mellem <quote +>SynthModule-objekt</quote +> og <quote +><acronym +>CORBA</acronym +>-grænsefladen</quote +> så naturlig ud, men den gjorde det aldrig, eftersom <acronym +>CORBA</acronym +> ikke kendte til noget om strømme overhovedet. &MCOP; gør det. Kig på koden (noget i stil med <filename +>simplesoundserver_impl.cc</filename +>). Adskilligt bedre! Strømme kan deklareres i modulernes grænseflade, og implementeres på en måde som ser naturlig ud. </para> + +<para +>Man kan ikke benægte det. En af grunderne til at jeg skrev &MCOP; var hurtighed. Her er et argument for at &MCOP; definitivt vil være hurtigere end &DCOP; (selv uden at angive tal). </para> + + +<para +>Et kald i &MCOP; vil have et hoved med seks <quote +>long</quote +>. Det vil sige: </para> + +<itemizedlist> +<listitem +><para +>magisk værdi <quote +>MCOP</quote +></para +></listitem> +<listitem +><para +>meddelelsetype (kald)</para +></listitem> +<listitem +><para +>størrelse på forespørgsler i byte</para +></listitem> +<listitem +><para +>ID for forespørgsler</para +></listitem> +<listitem +><para +>ID for målobjektet</para +></listitem> +<listitem +><para +>ID for målmetoden</para +></listitem> +</itemizedlist> + +<para +>Efter dette følger parametrene. Bemærk at afkode dette går ekstremt hurtigt. Man kan bruge tabelopslag for at finde afkodningsfunktionen for objektet og metoden, hvilket betyder at kompleksiteten er O(1) [det tager lige lang tid uafhængig af hvor mange objekter som findes, og hvor mange funktioner som findes]. </para> + +<para +>Hvis dette sammenlignes med &DCOP;, ser du at der er i det mindste </para> + +<itemizedlist> +<listitem +><para +>en streng for målobjektet - noget i stil med <quote +>myCalculator</quote +></para +></listitem +> +<listitem +><para +>en streng som ligner <quote +>addNumber(int,int)</quote +> for at angive metoden</para +></listitem> +<listitem +><para +>yderligere protokolinformation tilføjet af libICE, og andre DCOP-specifikke ting som jeg ikke kender til</para +></listitem> +</itemizedlist> + +<para +>Disse er meget sværere at afkode, eftersom man skal tolke strengen, lede efter funktionen, osv. </para> + +<para +>Med &DCOP; sendes alle kald gennem en server (<application +>DCOPServer</application +>). Det betyder at håndteringen af et synkront kald ser sådan her ud: </para> + +<itemizedlist> +<listitem> +<para +>Klientprocessen sender kald. </para> +</listitem> + +<listitem> +<para +><application +>DCOPserver</application +> (manden i midten) tager imod kaldet og ser efter hvor det skal hen, og sender det til den <quote +>rigtige</quote +> server. </para> +</listitem +> + +<listitem> +<para +>Serverprocessen tager imod kaldet, udfører forespørgsler og sender resultatet. </para> +</listitem> + +<listitem> +<para +><application +>DCOPserver</application +> (manden i midten) tager imod resultatet og ... sender det til klienten. </para> +</listitem> + +<listitem> +<para +>Klienten afkoder svaret. </para> +</listitem> +</itemizedlist> + +<para +>I &MCOP; ser samme kald ud sådan her ud: </para> + +<itemizedlist> +<listitem> +<para +>Klientprocessen sender kald. </para> +</listitem> + +<listitem> +<para +>Serverprocessen tager imod kaldet, udfører forespørgsler og sender resultatet. </para> +</listitem> + +<listitem> +<para +>Klienten afkoder svaret. </para> +</listitem> +</itemizedlist> + +<para +>Antag at begge er rigtigt implementerede. &MCOP;'s ikke-hierarkiske strategi bør være hurtigere med en faktor to, end &DCOP;'s mand i midten-strategi. Bemærk dog at der naturligvis var grunde til at vælge &DCOP;-strategien, som er at hvis du har 20 programmer som kører, og hvert program taler med hvert andet program, så behøver man 20 forbindelser med &DCOP;, og 200 med &MCOP;. I tilfældet med multimedie er det dog ikke meningen at dette skal være et almindeligt scenario. </para> + +<para +>Jeg forsøgte at sammenligne &MCOP; og &DCOP;, med at gøre et kald som lægger to tal sammen. Jeg ændrede testdcop for at opnå dette. Testen var dog måske ikke præcis på &DCOP;-siden. Jeg kaldte metoden i samme proces som gjorde kaldet til &DCOP;, og jeg vidste ikke hvordan man blev af med en fejlsøgningsmeddelelse, så jeg brugte omdirigering af udskriften. </para> + +<para +>Testen brugte kun et objekt og en funktion, så resultaterne for &DCOP; forventes at blive mindre med flere objekt og funktioner, mens resultaterne for &MCOP; bør forblive de samme. Desuden var <application +>dcopserver</application +>-processen ikke forbundet til andre programmer, og det er måske sådan at hvis mange programmer er forbundne så mindskes overføringsydelsen. </para> + +<para +>Resultatet jeg fik var at mens &DCOP; fik lidt mere end 2000 kald pr sekund, fik &MCOP; noget mere end 8000 kald pr sekund. Det betyder en faktor 4. Jeg véd at &MCOP; ikke er afstemt for den maksimalt mulige hastighed endnu. (Som sammenligning: <acronym +>CORBA</acronym +>, med mico-implementationen, klarer noget mellem 1000 og 1500 kald pr sekund). </para> + +<para +>Hvis du vil have <quote +>rigtigere</quote +> data, så overvej at skrive et lille måleprogram for &DCOP; og send det til mig. </para> + +<para +><acronym +>CORBA</acronym +> havde den behagelige funktion at man kunne bruge objekter som man havde implementeret, som <quote +>separat serverproces</quote +>, eller som <quote +>bibliotek</quote +>. Man kunne bruge samme kode for at gøre det, og <acronym +>CORBA</acronym +> bestemte transparent hvad der skulle gøres. Med &DCOP;, er det ikke rigtigt meningen, og så vidt jeg ved ikke egentlig muligt. </para> + +<para +>&MCOP; på den anden siden skulle understøtte dette fra begyndelsen. Så man kan køre en effekt inde i &artsd;. Men for en bølgeformseditor kan man også vælge at køre samme effekt inde i processen. </para> + +<para +>Mens &DCOP; i hovedsagen er en måde at kommunikere mellem programmer, er &MCOP; også en måde at kommunikere inde i programmerne. Især for multimediestrømme er dette vigtigt (eftersom man kan køre flere &MCOP;-objekter parallelt, for at løse en multimediaopgave i et program). </para> + +<para +>Selvom &MCOP; ikke gør det for øjeblikket, er mulighederne åbne for at implementere servicekvalitetsfunktioner. Noget i stil med at <quote +>den &MIDI;-begivenhed er virkelig rigtigt vigtig, sammenlignet med dette kald</quote +>. Eller noget som <quote +>skal være der til tiden</quote +>. </para> + +<para +>På den anden siden kan strømoverførsler integreres i &MCOP;-protokollen på en behagelig måde, og kombineres med <acronym +>QoS</acronym +>-ting. Under forudsætning af at protokollen kan ændres, bør &MCOP; strømoverførsler ikke blive virkelig langsommere end en konventionel <acronym +>TCP</acronym +>-strøm, men de vil være enklere og mere konsekvente at bruge. </para> + +<para +>Der er ingen grund til at basere mellemprogrammer for multimedie på &Qt;. Ved at bestemme sig for det, og bruge alle de behagelige &Qt;-strømme og andre ting, kan det let føre til at mellemprogrammer kun bliver en sag for &Qt;-(eller i virkeligheden kun &kde;). Jeg mener at hvis jeg nogensinde ser at GNOME også bruger &DCOP;, eller noget lignende, er det naturligvis beviset for at jeg har taget fejl. </para> + +<para +>Selvom jeg ved at &DCOP; i grunden ikke kender til de datatyper som den sender, så man ville kunne bruge &DCOP; uden &Qt;, se hvordan den bruges i daglig &kde;-brug: man sender typer rundt såsom <classname +>QString</classname +>, <classname +>QRect</classname +>, <classname +>QPixmap</classname +>, <classname +>QCString</classname +>, .... Disse bruger &Qt;'s-serialisering. Så hvis nogen vælger at understøtte &DCOP; i et GNOME-program, skal han enten angive at han bruger <classname +>QString</classname +>,... typer (selvom han ikke gør det), og emulere måden som &Qt; bruger til strømme, eller også skulle han sende andre streng-, pixmap- og rect-typer rundt, og på den måde alligevel ikke kunne virke sammen med &kde;-programmer. </para> + +<para +>Nå, under alle omstændigheder var det altid meningen at &arts; var beregnet til at virke med eller uden &kde;, med eller uden &Qt;, med eller uden X11, og måske til og med med eller uden &Linux; (og jeg har ikke engang indvendinger mod personer som tilretter den til operativsystemer som ikke er frie). </para> + +<para +>Min indstilling er at komponenter som ikke indgår i en grafisk grænseflade skal skrives uafhængig af denne, for at muliggøre at de deles mellem et større antal udviklere (og brugere). </para> + +<para +>Jeg indser at brug af to <acronym +>IPC</acronym +>-protokoller kan være ubekvemt. Desuden er begge to ikke standardiserede. Af de grunde som blev angivet ovenfor er det ikke muligt at skifte til &DCOP;. Hvis der er betydeligt interesse i at finde en måde at forene de to, så kan vi forsøge. Vi ville til og med kunne forsøge at få &MCOP; til at tale <acronym +>IIOP</acronym +>, når skulle vi have en <acronym +>CORBA</acronym +> <acronym +>ORB</acronym +> ;). </para> + +<para +>Jeg talte en del med Matthias Ettrich om fremtiden med de to protokoller, og vi fandt mange måde som tingene kunne gå videre. &MCOP; ville for eksempel kunne håndtere meddelelsekommunikationen i &DCOP;, og på denne måde få protokollerne nærmere til hinanden </para> + +<para +>Nogle mulige løsninger ville være: </para> + +<itemizedlist> +<listitem> +<para +>Skriv en portal mellem &MCOP; og &DCOP; (hvilket bør være muligt, og ville muliggøre samkørsel). Bemærk at der findes en eksperimentel prototype, hvis du skulle have lyst til at arbejde med det. </para> +</listitem> + +<listitem> +<para +>Integrér alt det &DCOP;-brugere forventer sig i &MCOP;, og forsøg kun at bruge &MCOP; - man skulle også kunne tilføje en <quote +>mand i midten</quote +> mulighed i &MCOP;) </para> +</listitem> + +<listitem> +<para +>Basér &DCOP; på &MCOP; i stedet for libICE, og begynd langsomt at integrere tingene tættere sammen. </para> +</listitem> +</itemizedlist> + +<para +>Den værste mulighed er måske ikke at bruge hver protokol til alt det som den var beregnet til (der er nogle store forskelle i målene med deres konstruktion), og ikke forsøge slå dem sammen til et. </para> + +</sect1> +</chapter> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/midi.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/midi.docbook new file mode 100644 index 00000000000..77a7fe72308 --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/midi.docbook @@ -0,0 +1,524 @@ +<!-- <?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 +>Oversigt</title> + +<!-- what-to-say-here: aRts has three roles + * moving midi events around between applications + * abstracting the hardware + * synthesizer --> + +<para +>&MIDI;-understøttelsen i &arts; kan gøre et antal forskellige ting. For det første, tillader den <emphasis +>kommunikation</emphasis +> mellem forskellige dele af programmellet som producerer eller konsumerer &MIDI;-begivenheder. Hvis du for eksempel har en sequencer og en samplingsenhed som begge bruger &arts;, kan &arts; sende &MIDI;-begivenheder fra sequenceren til samplingsenheden. </para> + +<para +>På den anden side kan &arts; også hjælpe programmer til at <emphasis +>vekselvirke med maskinellet</emphasis +>. Hvis en programmeldel (for eksempel samplingen) virker sammen med &arts;, kan den desuden tage imod &MIDI;-begivenheder fra et eksternt &MIDI;-keyboard. </para> + +<para +>Til slut, så udgør &arts; en udmærket <emphasis +>modulær synthesizer</emphasis +>. Den er konstrueret til at gøre netop dette. Man kan altså bygge instrumenter af små moduler med aRts-byggeren, og derefter bruge instrumenterne til at komponere eller spille musik. Syntese betyder ikke nødvendigtvis kun ren syntese, men der er moduler som kan bruges til at afspille samplinger. På denne måde kan &arts; være både en samplingsenhed eller synthesizer, og eftersom den er fuldstændig modulær, er den meget let at udvide, meget let at eksperimentere med, kraftfuld og fleksibel. </para> +</sect1> + +<sect1 id="midi-manager"> +<title +>&MIDI;-håndteringen</title> +<!-- what-to-say-here: + * how to use artscontrol - view midimanager + * what does autorestore do? (not yet implemented - so not yet documented) --> + +<para +>Den centrale komponent i &arts; som holder rede på hvilke programmer der er tilsluttet og hvordan midi-begivenheder skal sendes mellem dem er midi-håndteringen. For at se eller påvirke hvad den gør, startes artscontrol. Derefter vælges <menuchoice +><guilabel +>Vis</guilabel +><guilabel +>Vis midihåndtering</guilabel +> </menuchoice +> i menuen. </para> + +<para +>Til venstre ser man <guilabel +>Midi-inddata</guilabel +>. Der er alle objekter som producerer &MIDI;-begivenheder på en liste, såsom en ekstern &MIDI;-port som sender data fra et tilsluttet &MIDI;-keyboard, en sequencer som spiller en sang og så videre. Til højre ser man <guilabel +>Midi-udskrift</guilabel +>. Der er alting som konsumerer &MIDI;-begivenheder på en liste, såsom en simuleret samplingsenhed (programmel), eller den eksterne &MIDI;-port som en hardware-samplingsenhed der er tilsluttet udenfor din maskine. Nye programmer, såsom en sequencer eller lignende, registrerer sig selv, så at listen ændres med tiden. </para> + +<para +>Du kan tilslutte indgange og udgange hvis du markerer en indgang i listen til venstre og en udgang til højre, og vælger <guilabel +>Forbind</guilabel +> med knappen nedenfor. <guilabel +>Afbryd forbindelse</guilabel +> virker på samme måde. Du ser hvad der er tilsluttet som små linjer mellem indgange og udgange, midt i vinduet. Bemærk at du kan tilslutte en indgang til mere end en udgang (og omvendt). </para> + +<para +>Programmer (såsom sequenceren Brahms) tilføjes af sig selv når de startes og fjernes fra listen når de afsluttes. Men du kan også tilføje nye enheder med menuen <guilabel +>Tilføj</guilabel +>. </para> + +<variablelist> +<varlistentry> +<term +><guimenuitem +>System midi port (OSS)</guimenuitem +></term> +<listitem> +<para +>Dette laver et nyt &arts;-objekt som kommunikerer med en ekstern midi-port. </para> + +<para +>Eftersom eksterne midi-porte både kan sende og modtage data, så tilføjes både en indgang og udgang med dette valg. Med &Linux;, skal du enten have en <acronym +>OSS</acronym +>-driver (eller <acronym +>OSS</acronym +>/Free, som følger med &Linux;-kernen) eller en <acronym +>ALSA</acronym +>-driver installeret for dit lydkort, for at dette skal virke. Du bliver spurgt om enhedens navn. Dette er oftest <filename class="devicefile" +>/dev/midi</filename +> eller <filename class="devicefile" +>/dev/midi00</filename +>. </para> + +<para +>Hvis du har mere end en &MIDI;-enhed eller en &MIDI;-tilbagekoblingsenhed installeret, kan der dog være flere valgmuligheder. For at vise information om midi-porte, startes &kcontrolcenter;, og <menuchoice +><guilabel +>Information</guilabel +> <guilabel +>Lyd</guilabel +></menuchoice +> vælges. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>aRts syntese midi-uddata</guimenuitem +></term> +<listitem> +<para +>Dette tilføjer en ny &MIDI;-udgang med et &arts; synteseinstrument. Hvis du vælger menupunktet, kommer en dialog frem, som lader dig angive et instrument. Du kan oprette nye instrumenter med artsbuilder. Alle <literal role="extension" +>.arts</literal +>-filer med et navn som begynder med <filename +>instrument_</filename +> vises her. </para> +</listitem> +</varlistentry> +</variablelist> + +</sect1> + +<sect1 id="brahms"> +<title +>Brug af &arts; & Brahms</title> + +<para +>I virkeligheden er det rigtig let at komme i gang. Du behøver en version af Brahms som virker med &kde; 2.1, som findes i <literal +>kmusic</literal +> <acronym +>CVS</acronym +>-modulet. Der er også information om hvordan man får fat på &brahms; på <ulink url="http://www.arts-project.org/" +>aRts' hjemmeside</ulink +> i afsnittet om download. </para> + +<para +>Når du har startet programmet, ses det i &MIDI;-håndteringen. Hvis du vil bruge syntese, så tilføj helt enkelt et &MIDI;-instrument med <menuchoice +><guilabel +>Tilføj</guilabel +><guilabel +>aRts syntese midi uddata</guilabel +></menuchoice +>. </para> + +<para +>Vælg et instrument (for eksempel <guilabel +>organ2</guilabel +>). Forbind dem ved brug af knappen <guilabel +>Forbind</guilabel +>. Derefter kan du begynde at komponere i &brahms;, og resultatet syntetiseres med &arts;. </para> + +<para +>Det er oftest en god ide at have &artscontrol;-vinduet åbent, og se at lydstyrken ikke er for høj (lydkvaliteten bliver dårligere når bjælkerne når den øvre grænse). Nu kan du begynde at skrive en ny &arts; demo, og når du er klar kan du få den publiceret på aRts-project.org ;-). </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 +> er et lille program som lader dig sende &MIDI;-begivenheder fra skallen. Det registreres som en klient ligesom alle andre programmer. Den enkleste måde at bruge det er at skrive <screen +><prompt +>%</prompt +> <userinput +><command +>midisend</command +> <option +>-f</option +> <parameter +><replaceable +>/dev/midi00</replaceable +></parameter +></userinput +> </screen +> hvilket opnår cirka det samme som at tilføje en &MIDI;-port til &artscontrol;. (Ikke helt, fordi <command +>midisend</command +> kun sender begivenheder). Forskellen er at det er for eksempel er let at starte <command +>midisend</command +> på forskellige computere (og på den måde bruge netværkstransparens). </para> + +<para +>Det er også muligt at lade <command +>midisend</command +> sende data fra <filename class="devicefile" +>stdin</filename +>, hvilket du kan bruge til at sende data fra programmer som ikke understøtter &arts;, sådan her: <screen +><prompt +>%</prompt +> <userinput +><command +><replaceable +>program_som_sender_MIDI_begivenheder_til_standarduddata</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 +>Opret instrumenter</title> + +<para +>Den måde &arts; udfører midi-syntese er følgende: Du har strukturer som har et antal indgange, hvor de henter frekvensen, hastigheden (lydstyrke) og en parameter som angiver om tasten stadigvæk er trykket ned. Strukturen skal nu syntetisere nøjagtigt den tone med den lydstyrke, og reagere på parameteren pressed (hvor pressed = 1 betyder at brugeren holder tasten nede og pressed = 0 betyder at brugeren har sluppet tasten). </para> + +<para +>Når &MIDI;-begivenheder ankommer, laver &arts; nye strukturer for tonerne efter behov, angiver parametrene, og rydder dem væk når de er færdige. </para> + +<para +>For at oprette og bruge en sådan struktur, skal du gøre følgende: </para> + +<itemizedlist> +<listitem> +<para +>For at komme i gang er den behageligste måde at åbne <filename +>template_Instrument.arts</filename +> i &arts-builder;. </para> + +<para +>Dette kan opnås ved at bruge <menuchoice +><guimenu +>Fil</guimenu +><guimenuitem +>Åbn eksempel...</guimenuitem +></menuchoice +> og vælge <guimenuitem +>template_Instrument</guimenuitem +> i fildialogen. Dette laver en tom struktur med de nødvendige parametre, som du kun behøver <quote +>udfylde</quote +>. </para> +</listitem> + +<listitem> +<para +>For at håndtere parameteren "pressed", er det praktisk at bruge Synth_ENVELOPE_ADSR, eller hvis en wav-fil med tromme spilles, så spil den blot alligevel og ignorér parameteren. </para> +</listitem> + +<listitem> +<para +>Strukturen skal indikere hvornår den ikke behøves længere med uddata <quote +>done</quote +>. Hvis done er <returnvalue +>1</returnvalue +>, antager &arts; at strukturen kan slettes. Praktisk nok så sørger ADSR-envelopen for en parameter som angiver når den er færdig, så du behøver kun forbinde den til done-udgangen for strukturen. </para> +</listitem> + +<listitem> +<para +>Du bør omdøbe din struktur til et navn som begynder med <filename +>instrument_</filename +>, såsom <filename +>instrument_piano.arts</filename +> - du bør gemme filen under samme navn i mappen <filename class="directory" +>$<envar +>HOME</envar +>/arts/structures</filename +> (hvor artsbuilder normalt gemmer filer). </para> +</listitem> + +<listitem> +<para +>Til sidst, når du har gemt den, kan du bruge den med &artscontrol; i &MIDI;-håndteringen.</para> +</listitem> + +<listitem> +<para +>Åh, og din struktur skal naturligvis afspille lyddata som den laver via venstre og højre udgang for strukturen, som siden afspilles med lydhåndteringen (du kan se dette i &artscontrol;), så du til slut kan høre lyden (eller efterbehandle den med lydeffekter). </para> +</listitem> +</itemizedlist> + +<para +>En god måde at lære sig hvordan man laver instrumenter er at åbne et eksisterende instrument med <menuchoice +><guilabel +>Fil</guilabel +><guilabel +>Åbn eksempel</guilabel +> </menuchoice +> og se hvordan det virker ;) </para> +</sect1> + +<sect1 id="mapped-instruments"> +<title +>Instrumentkort</title> + +<para +>Instrumentkort er instrumenter som opfører sig forskelligt afhængig af tonehøjden, programmet, kanalen eller hastigheden. Man kan for eksempel oprette et piano med fem oktaver, og bruge en sampling for hver oktav (med tonehøjden forskudt tilsvarende). Dette lyder meget bedre end kun at bruge en sampling. </para> + +<para +>Man kan også bygge et trommekort, som spiller en særlig trommesampling for hver tast. </para> + +<para +>Til sidst er det meget nyttigt hvis man kombinerer helt forskellige lyde i et instrumentkort for forskellige programmer. På denne måde kan man bruge sin sequencer, eksterne keyboard eller en anden &MIDI;-kilde til at skifte mellem lyde uden at behøve at manipulere &arts; under arbejdets gang. </para> + +<para +>Et godt eksempel på dette er <filename +>arts_all</filename +>, som helt enkelt kombinerer alle instrumenter som levereres med &arts; i et kort. På denne måde behøver man kun angive at dette <quote +>instrument</quote +> skal bruges en gang i &artscontrol;, og derefter kan man komponere en hel sang i en sequencer uden overhovedet at bryde sig om &arts;. Brug for en anden lyd? Ændr helt enkelt programmet i sequenceren, og &arts; sørger for en ny lyd. </para> + +<para +>Oprettelse af sådanne kort er ganske ligetil. Man behøver kun at oprette en tekstfil, og skrive regler som ser sådan her ud: </para> + +<programlisting +>ON <replaceable +>[ betingelser ...]</replaceable +> DO structure=<replaceable +>en_struktur</replaceable +>.arts +</programlisting> + +<para +>Betingelserne kan være en eller flere af følgende: </para> + +<variablelist> + +<varlistentry> +<term +><option +>pitch</option +></term> + +<listitem> +<para +>Tonehøjden som spilles. Man bruger dette hvis man vil opdele instrumentet afhængig af tonhøjde. I vort oprindelige eksempel, skulle et piano som bruger forskellige samplinger for forskellige oktaver bruge dette som betingelser. Man kan angive en enkel tonehøjde, såsom <userinput +><option +>pitch</option +>=<parameter +>62</parameter +></userinput +> eller et interval af tonehøjder, såsom <userinput +><option +>pitch</option +>=<parameter +>60</parameter +>-<parameter +>72</parameter +></userinput +>. De mulige tonehøjder går mellem <parameter +>0</parameter +> og <parameter +>127</parameter +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>program</option +></term> +<listitem> +<para +>Programmet som er aktivt på kanalen som tonen afspilles i. Oftest lader sequenceren dig vælge <quote +>instrument</quote +> via programindstillingen. Enkle programmer eller intervaller er tilladte, dvs. <userinput +><option +>program</option +>=<parameter +>3</parameter +></userinput +> eller <userinput +><option +>program</option +>=<parameter +>3</parameter +>-<parameter +>6</parameter +></userinput +>. Mulige programmer går mellem <parameter +>0</parameter +> og <parameter +>127</parameter +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>channel</option +></term> +<listitem> +<para +>Kanalen som tonen sendes på. Enkle kanaler eller intervaller er tilladte, dvs. <userinput +><option +>channel</option +>=<parameter +>0</parameter +></userinput +> eller <userinput +><option +>channel</option +>=<parameter +>0</parameter +>-<parameter +>8</parameter +></userinput +>. Mulige kanaler går mellem <parameter +>0</parameter +> og <parameter +>15</parameter +>. </para> +</listitem> + +</varlistentry> +<varlistentry> +<term +><option +>velocity</option +></term> +<listitem> +<para +>Hastigheden (lydstyrken) som tonen har. Enkle hastigheder (hvem skulle ville bruge det?) eller intervaller er tilladte, dvs. <userinput +><option +>velocity</option +>=<parameter +>127</parameter +></userinput +> eller <userinput +><option +>velocity</option +>=<parameter +>64</parameter +>-<parameter +>127</parameter +></userinput +>. Mulige hastigheder går mellem <parameter +>0</parameter +> og <parameter +>127</parameter +>. </para> +</listitem> +</varlistentry> +</variablelist> + +<para +>Et fuldstændigt eksempel for et kort kan være (dette kommer fra den nuværende <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 +>Som du ser, vælges strukturen afhængig af programmet. For program 11, ses et <quote +>trommekort</quote +> (med to indgange), som vil spille en <quote +>deepdrum</quote +> med C-5 (tonehøjde = 60), og en <quote +>chirpdrum</quote +> med C#5 (tonehøjde = 61). </para> + +<para +>For at kortfiler automatisk skal ses i &artscontrol; som et valg for instrumenterne, skal de hedde <filename +>instrument_<replaceable +>noget</replaceable +>.arts-map</filename +> og enten være i din hjemmemappe i <filename class="directory" +>$<envar +>HOME</envar +>/arts/structures</filename +>, eller i &kde;-mappen i <filename class="directory" +>$<envar +>KDEDIR</envar +>/share/apps/artsbuilder/examples</filename +>. Strukturer som bruges af kortene kan enten angives med en absolut søgesti, eller relativt til mappen som kortfilen findes i. </para> + +<para +>Udvidelse af arts_all map eller til og med at lave et fuldstændigt generelt &MIDI;-kort for &arts; er en god idé for at gøre &arts; lettere at bruge direkte som det er. Overvej gerne at bidrage med interessante instrumenter som du laver, så de kan inkluderes i fremtidige udgaver af &arts;. </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-da/docs/tdemultimedia/artsbuilder/midiintro.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/midiintro.docbook new file mode 100644 index 00000000000..eb3caf8ed84 --- /dev/null +++ b/tde-i18n-da/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 +>Introduktion til <acronym +>MIDI</acronym +></title> + +<para +>Ikke skrevet endnu </para> + +</appendix> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/modules.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/modules.docbook new file mode 100644 index 00000000000..a49f27641ac --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/modules.docbook @@ -0,0 +1,1333 @@ +<!-- <?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;-moduler</title> + + <sect1 id="modules-introduction"> +<title +>Indledning</title> + +<para +>Dette kapitel beskriver alle standardmodulerne i &arts;. En af de mest kraftfulde funktioner i &arts; er at moduler kan sammenkobles til strukturer som implementerer nye funktioner såsom lydeffekter og instrumenter. </para> + +<para +>Moduler opdeles i to kategorier. Syntesemoduler bruges til at implementere <quote +>rørlægningen</quote +> som manipulerer multimedie-datastrømme for at lave nye effekter, instrumenter, miksere og programmer. Visuelle moduler tillader dig at oprette en grafisk grænseflade til at styre lydstrukturerne som opbygges med syntesemodulerne. </para> + +</sect1> + +<sect1 id="synth-modules-reference"> +<title +>Reference til syntesemoduler</title> + + +<sect2 id="mcat-synth-arithmetic-mixing"> +<title +>Aritmetik + miksning</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 +>Denne adderer to signaler. </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 +>Denne multiplicerer signalet med en faktor. Du kan bruge dette til at skalere signaler ned (0 < faktor < 1) eller op (faktor > 1) eller invertere signaler (faktor < 0). Bemærk at faktoren kan være et signal og ikke behøver at være konstant (f.eks. envelopper eller rigtige signaler). </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 +>Dette dividerer et signal med en faktor. Du kan bruge dette til at dividere et signal med et andet. Eller sætte indværdi11 til 1 så du derved får den reciprokke værdi af indværdi2 som udværdi. Pas på med at indværdi2 aldrig nærmer sig 0 ellers vil du få problemer med divisioner med nul. </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 +>Denne adderer et vilkårligt antal signaler. Hvis du har brug for at opsummere bølgeformer som slaves af fire forskellige oscillatorer, kan du for eksempel tilslutte alle deres udgange til et Synth_MULTI_ADD-modul. Dette er effektivere end at bruge tre Synth_ADD-moduler. </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 +>Denne overtoner to signaler. Hvis procentindgangen er -1, høres kun signalet til venstre, hvis den er 1, høres kun det til højre. Hvis den er 0, høres begge signalerne med samme lydstyrke. </para> + +<para +>Denne gør at du kan sørge for at signalerne bliver indenfor et veldefineret område. Hvis du har to signaler som er mellem -1 og 1 inden overtoningen, forbliver de i samme område bagefter. </para> +</sect3> + +<sect3 id="mref-synth-autopanner-sect"> +<title +>Synth_AUTOPANNER</title> +<anchor id="mref-synth-autopanner"/> + +<para +>Det modsatte af overtoning. Denne tager et monosignal og deler det op til et stereosignal. Den bruges til automatisk at panorere inddata-signalet mellem venstre og højre udgang. Dette gør miksningen mere levende. En standardanvendelse kunne være en guitar- eller sololyd. </para> + +<para +>Forbind en <acronym +>LFO</acronym +>, for eksempel en sinus eller savtakbølge til inlfo, og vælg en frekvens mellem 0,1 og 5 Hz for at få en traditionel effekt eller endnu mere for specialeffekter (<acronym +>FX</acronym +>). </para> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-busses"> +<title +>Busser</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 +>Et oplink til en bus. Angiv signaler til venstre og højre, og navnet på bussen som data skal sendes til på <quote +>bus</quote +>-porten. Det kombinerede signal fra alle oplink med dette navn havner på hvert nedlink på denne <quote +>bus</quote +>. </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 +>Henter (summen af) alle data som sendes på en vis bus (med navnet du angiver på <quote +>bus</quote +>-porten). </para> +</sect3> + +</sect2> + +<!-- TODO AFTER KDE2.1: move freeverb into delays, and rename category to + Delays & reverbs --> + +<sect2 id="mcat-synth-delays"> +<title +>Forsinkelser</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 +>Denne forsinker inddata-signalet en vis tid. Tidsangivelsen skal være mellem 0 og maxdelay for en forsinkelse mellem 0 og maxdelay sekunder. </para> + +<para +>Denne slags forsinkelse <emphasis +>kan ikke bruges</emphasis +> i tilbagemeldingsstrukturer. Dette skyldes at det er en varierbar forsinkelse. Det går an at ændre længden mens den kører, og endog sætte den til nul. Men eftersom de egne uddata behøves for at beregne næste sampling i en tilbagemeldingsstruktur, kan en forsinkelse med en værdi som kan gå ned til nul under syntese føre til en låsningssituation. </para> + +<para +>Brug CDELAY'er i sådanne situationer, eller kombinér en kort konstant forsinkelse (på 0,001 sekunder) med en variabel forsinkelse. </para> + +<para +>Man kan også kombinere en CDELAY og en DELAY for at opnå en forsinkelse med variabel længde i en tilbagekobling. Sørg blot for at du har med en CDELAY at gøre. </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 +>Denne forlænger inddatasignalet en vis tid. Tidsangivelsen skal være større end 0 for en forsinkelse af på sekunder eller mere. Forsinkelsen er konstant under beregningen, hvilket betyder at den ikke kan ændres. </para> + +<para +>Dette sparer beregningstid eftersom ingen interpolation gøres, og er nyttigt til rekursive strukturer. Se beskrivelsen ovenfor (Synth_DELAY). </para> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-envelopes"> +<title +>Enveloper</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 +>Dette er en klassisk <acronym +>ADSR</acronym +>-envelop, som betyder at du angiver: </para> + +<variablelist> +<varlistentry> +<term +>active</term> +<listitem> +<para +>Hvis brugeren holder tasten nede lige nu. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>invalue</term> +<listitem> +<para +>Inddatasignalet. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>attack</term> +<listitem> +<para +>Tiden som skal gå fra brugerens tryk på tasten og til signalet når sin maksimale amplitude (i sekunder). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>decay</term> +<listitem> +<para +>Tiden som skal gå fra signalet har nået sin maksimale amplitude til signalet går tilbage til et konstant niveau (i sekunder). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>sustain</term> +<listitem> +<para +>Det konstante niveau som holdes for signalet bagefter, til brugeren slipper tasten. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>release</term> +<listitem> +<para +>Tiden som skal gå fra brugeren har sluppet tasten til signalet går ned til nul (i sekunder). </para> +</listitem> +</varlistentry> +</variablelist> + +<para +>Du får det behandlede signal som uddata-værdi. Når <acronym +>ASDR</acronym +>-envelopen er klar, sætter den done til 1. Du kan bruge dette til at sørge for uddata <quote +>done</quote +> for et instrument (som gør at instrumentstrukturen fjernes fra &MIDI;-relæobjektet når lyden er hørt op). </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 +>Modulet Synth_PSCALE vil skalere lydstrømmen som sendes gennem den fra lydstyrke 0 (tavs) til 1 (oprindelig lydstyrke) tilbage til 0 (tavs), ifølge positionen (hent positionen fra en Synth_SEQUENCE). Positionen hvor toppen skal være kan angives som pos. </para> + +<para +>Eksempel: sæt top til 0,1 betyder at efter at 10 % af tonen er afspillet, har lydstyrken nået sin maksimale værdi, og begynder derefter at aftage. </para> +</sect3> + +</sect2> + +<sect2 id="mcat-synth-effects"> +<title +>Effekter</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 +>Dette er en efterklangseffekt. I den nuværende implementering er det tænkt at sende en stereosignal gennem modulet, og det vil så -tilføje- efterklangseffekten til signalet. </para> + +<note> +<para +>Dette betyder at den også kan bruges inde i en StereoEffectStack. </para> +</note> + +<para +>Inddata-signalet skal forbindes til (inleft, inright), og uddata-signalet bliver (outleft, outright). </para> + +<para +>Parametrene som du kan indstille er: </para> + +<variablelist> +<varlistentry> +<term +>roomsize</term> +<listitem> +<para +>Størrelsen af rummet som efterklangseffekten simulerer (område: 0 .. 1, hvor 1 er det største mulige rum). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>damp</term> +<listitem> +<para +>Dette angiver et filter som gør at det simulerede rum absorberer høje frekvenser (område 0 .. 1, hvor 1 betyder absorbere høje frekvenser i stor udstrækning). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>wet</term> +<listitem> +<para +>Størrelsen af efterklangsignalet (dvs. den del af signalet som skal ændres af filtret, og forårsage en <quote +>vådt</quote +> lyd, dvs. en <quote +>efterklangslyd</quote +>). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>dry</term> +<listitem> +<para +>Størrelsen af rent signal som sendes gennem, som forårsager et ekko (eller kombineret forsinkelse) i stedet for en efterklangseffekt (område: 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 +>Størrelsen af udvidet stereoeffekt som efterklangsalgoritmen tilføjer til efterklangseffekten, for at gøre efterklangslyden bredere i stereolydbilledet (område 0 .. 1). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>mode</term> +<listitem> +<para +>[HUSK: Jeg tror at hvis mode er 1, beholder efterklangen det nuværende lydbillede for lyden, mens 0 er normal behandling] </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 +>Tremolomodulet modulerer amplituden ifølge en <acronym +>LFO</acronym +>-bølgeform. Traditionelt bruger man en sinusbølge, men hvorfor begrænse sig? Hvad man får er en meget intensiv effekt som skærer gennem de fleste arrangementer på grund af sit store dynamiske omfang. Tremoloeffekten er stadigvæk en favoriteffekt bland guitarister, selvom den ikke er så populær som i tresserne. </para> + +<para +>[HUSK: for øjeblikket implementeres dette som invalue + abs(inlfo) - måske ville det være bedre at implementere det som invalue * (1+inlfo*depth), hvor depth ville være en parameter mellem 0 .. 1 - dette afgøres efter &kde;2.1. Hvis du har en kommentar, så skriv til &arts;' e-mail-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 +>En flanger er en tidsvariabel forsinkelseseffekt. For at gøre udvikling af komplekse flangereffekter enklere, leveres dette modul som indeholder kernen af en enkanals flangerenhed. </para> + +<para +>Den har følgende porte:</para> + +<variablelist> +<varlistentry> +<term +>invalue</term> +<listitem> +<para +>Signalet som du vil behandle. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>lfo</term> +<listitem> +<para +>Helst en sinusbølge som modulerer forsinkelsestiden inde i flangeren (-1 .. 1). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>mintime</term> +<listitem> +<para +>Den minimale værdi for tiden inde i flangeren i millisekunder. Foreslåede værdier: forsøg med noget i retning af 1 ms. Brug helst værdier < 1000 ms. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>maxtime</term> +<listitem> +<para +>Den maksimale værdi for tiden inde i flangeren i millisekunder. Foreslåede værdier: forsøg med noget i retning af 5 ms. Brug helst værdier < 1000 ms. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>outvalue</term> +<listitem> +<para +>Uddatasignalet. Det er vigtigt at du blander dette med originalsignalet (uden flanger) for at få den ønskede effekt. </para> +</listitem> +</varlistentry> +</variablelist> + +<tip> +<para +>Du kan bruge dette som en basis for koreffekter. </para> +</tip> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-filters"> +<title +>Filtre</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 +>Denne tonehøjdeforandrende effekt ændrer frekvensen på inddatasignalet uden at påvirke hastigheden. En anvendelse af dette er for eksempel at ændre tonehøjden på din stemme mens du indspiller (og afspiller) den i realtid. </para> + +<para +>Parameteren <emphasis +>speed</emphasis +> er den relative hastighed som signalet afspilles med. Så med en hastighed på to bliver lyden dobbelt så høj (dvs. en inddatafrekvens på 440 Hz giver en uddatafrekvens på 880 Hz). </para> + +<para +>Parameteren <emphasis +>frequency</emphasis +> bruges internt til at ændre mellem forskellige korn i signalet. Den er indstillelig, og afhængig af valget kommer tonehøjdens ændring til at lyde mere eller mindre realistisk i dit brugstilfælde. En god værdi at begynde med er noget i stil med 5 eller 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 +>Filtrerer alle frekvenser væk over afskæringsfrekvensen. </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 +>Dette modul klipper et signal så det passer i området [-1;1]. Det gør ingenting for at begrænse den forvridning som opstår når et stærk signal klippes af. Man kan bruge dette som en lydeffekt (for eksempel til at oprette en noget afklippet sinusbølge). Det er dog oftest en god idé at lade signalet gå gennem et lowpass-filter bagefter hvis du gør dette, for at gøre lyden mindre skærende. </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 +>Dette er en god byggeblok for en parametriserbar tonekontrol. Dens parametre er: </para> + +<variablelist> +<varlistentry> +<term +>Indværdi, udværdi</term> +<listitem> +<para +>Signalet som filtreres af tonekontrollen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>low</term> +<listitem> +<para +>Hvordan lave frekvenser skal ændres. Værdien angives i dB, mens 0 betyder at lave frekvenser ikke skal ændres, ville -6 betyde at de dæmpes med 6 dB, og +6 betyder at de øges med 6 dB. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>mid</term> +<listitem> +<para +>Hvordan middelfrekvenser skal ændres af tonekontrollen i dB (se low). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>high</term> +<listitem> +<para +>Hvordan høje frekvenser skal ændres af tonekontrollen i dB (se low). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>frekvens</term> +<listitem> +<para +>Dette er midtfrekvensen for tonekontrollen i Hz, midtfrekvensen befinder sig omkring dette spektrum, med de lave og høje frekvenser nedenfor og ovenfor. Bemærk at frekvensen ikke kan være højere end en halvdel af samplingsfrekvensen, oftest er den 22050 Hz, og ikke lavere end 1 Hz. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>q</term> +<listitem> +<para +>Dette påvirker hvor bredt midterspektret er. Det skal være et positivt tal > 0. En værdi på et er rimelig, højere værdier af q betyder et smallere spektrum af midterfrekvenser. Lavere værdier end et betyder et bredere spektrum. </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 +>Et dæmpet resonansfilter som filtrerer alle frekvenser omkring en højeste værdi. Der er ingen nyttig måde at angive en midterfrekvens (som ikke skal klippes ), eftersom inddata er to underlige konstanter f og b. Koden er meget gammel, fra synthesizerns tidligste dage, og vil formodentlig blive skiftet ud mod et nyt filter som har en frekvens og en resonansværdi som parametre. </para> + +<para +>Forsøg med noget som ligner b=5, f=5 or b=10, f=10 or b=15, f=15 i alle tilfælde. </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 +>Filtrerer alle frekvenser væk over afskæringsfrekvensen (det er et 24 dB firepols filter, som filtrerer 24 dB pr oktav over afskæringsfrekvensen), men sørger for en yderligere parameter til at indstille filtrets resonans, hvor 0 betyder ingen resonans og 4 betyder selvsving. </para> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-midi-sequencing"> +<title +>Midi + sekvensering</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 +>Dette modul indlæser en instrumentstruktur fra en fil, og registrerer sig som en midi-udgang med &arts; &MIDI;-håndtering. Toner som sendes til denne udgang gør at instrumentstemmer laves. </para> + +<note> +<para +>Du kan indstille noget sådant her på en behageligere måde i &artscontrol; i stedet for manuelt i &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 +>Afspiller en sekvens af toner om og om igen. Tonerne angives i spornotation, og adskilles af semikolon. Et eksempel er <literal +>A-3;C-4;E-4;C-4;</literal +>. Hastigheden angives som sekunder pr tone, så hvis du vil angive 120 slag pr minut, angiver du formodentlig 0,5 sekunder/tone, idet 60 sekunder/0,5 sekunder pr tone = 120 slag pr minut. </para> + +<para +>Du kan give hver tone en længde i forhold til hastigheden ved at bruge et kolon efter tonen fulgt af længden. <literal +>A-3:2;C-4:0.5;D-4:0.5;E-4;</literal +> viser dette. Som du kan se, tenderer midi-tonesætningsprogrammer til at tilbyde større bekvemmelighed ;) </para> + +<para +>Synth_SEQUENCE giver yderligere information om positionen for tonen som afspilles lige nu, hvor 0 betyder lige påbegyndt og 1 betyder afsluttet. Denne information kan man bruge med Synth_PSCALE (se nedenfor). </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 +>Dette modul virker præcis som Synth_SEQUENCE, med den eneste forskel at du ikke indskriver nodenavne men frekvenser. </para> + +</sect3> + +</sect2> + +<sect2 id="mcat-synth-samples"> +<title +>Samplinger</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 +>Dette afspiller en <literal role="extension" +>wav</literal +>-fil. Den er kun tilstede hvis du har libaudiofile på computeren. Bølgeformsfilen afspilles så snart modulet laves. </para> + +<para +>Den stopper så snart den er klar, og done sættes til 1. Hastighedsparameteren kan bruges til at afspille filen hurtigere eller langsommere, hvor 1.0 er den normale (indspillede) hastighed. </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 +>Lyd-I/O</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 +>Normalt behøver man ikke dette modul, hvis man ikke skriver selvstændige programmer. Inde i &artsd;, er der allerede et Synth_PLAY modul, og at oprette et til virker ikke. </para> +</important> + +<para +>Modulet Synth_PLAY giver lydsignalet som uddata til lydkortet. Venstre og højre kanal skal indeholde <emphasis +>normaliseret</emphasis +> inddata for kanalerne. Hvis inddata ikke er mellem -1 og 1, får man klipning. </para> + +<para +>Som allerede nævnt, må der kun være et Synth_PLAY modul, eftersom det har direkte adgang til lydkortet. Brug busser til at blande mere end en lydstrøm sammen inden afspilning. Brug modulet Synth_AMAN_PLAY for at få noget som ligner uddata inde i &artsd;. </para> + +<para +>Bemærk at Synth_PLAY også kontrollerer tiden for hele strukturen. Dette betyder: ingen Synth_PLAY = ingen kilde for tid = ingen lyd. Så der behøves (nøjagtigt) et 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 +>Normalt behøver man ikke dette modul, hvis man ikke skriver selvstændige programmer. Inde i artsd, er der normalt allerede et Synth_RECORD modul, og at oprette et til virker ikke. </para> +</important> + +<para +>Modulet Synth_RECORD indspiller et signal fra lydkortet. Venstre og højre kanal indeholder inddata for kanalerne (mellem -1 og 1). </para> + +<para +>Som allerede nævnt, må der kun findes et Synth_RECORD modul, eftersom det har direkte adgang til lydkortet. Brug busser for at bruge den indspillede lydstrøm på mere end et sted. Brug modulet Synth_AMAN_RECORD for at få noget som ligner en indgang inde i artsd. For at dette skal virke skal &artsd; køre <emphasis +>med full dupleks aktiveret</emphasis +>. </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 +>Modulet Synth_AMAN_PLAY giver lydsignalet som uddata. Det er godt (men ikke nødvendigt) at uddata er et normaliserer signal (mellem -1 og 1). </para> + +<para +>Dette modul bruger lydhåndteringen til at angive hvor signalet bliver spillet. Lydhåndteringen kan styres gennem &artscontrol;. For at gøre det mere intuitivt at bruge, er det godt at navngive signalet som afspilles. Det kan opnås ved at angive <emphasis +>title</emphasis +>. En anden funktion i lydhåndteringen er at kunne huske hvor et signal sidst blev afspillet. For at kunne gøre dette skal den kunne skelne mellem signaler. Derfor skal man også angive en entydig værdi for <emphasis +>autoRestoreID</emphasis +>. </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 +>Modulet Synth_AMAN_RECORD optager et lydsignal fra en ekstern kilde (dvs. linje ind/mikrofon) inde i &artsd;. Uddata vil være et normaliseret signal (mellem -1 og 1). </para> + +<para +>Dette modul bruger lydhåndteringen til at angive hvor signalet afspilles. Lydhåndteringen kan styres med artscontrol. For at gøre det mere intuitivt at bruge, er det godt at navngive signalet som afspilles. Det kan opnås ved at angive <emphasis +>title</emphasis +>. En anden funktion i lydhåndtereringen er at kunne huske hvor et signal afspilledes sidst. For at kunne gøre dette skal den kunne skelne mellem signaler. Derfor skal man også angive en entydig værdi for <emphasis +>autoRestoreID</emphasis +>. </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 +>Modulet Synth_CAPTURE skriver et lydsignal til en bølgeformsfil på harddisken. Filen hedder altid <filename +>/tmp/mcop-<replaceable +>brugernavn</replaceable +>/capture.wav</filename +> </para> +</sect3> + +</sect2> + +<sect2 id="mcat-synth-tests"> +<title +>Tester</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 +>Dette gør ingenting. Det er meget nyttigt i testsituationer. </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 +>Man kan bruge dette til fejlsøgning. Det udskriver værdien for signalet ved invalue i regelmæssige intervaller (cirka 1 sekund), sammen med kommentaren som du har angivet. På denne måde kan man finde ud af om visse signaler forbliver indenfor visse områder, eller om de findes i det hele taget. </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 +>Man kan bruge dette til at fejlsøge hvordan &MIDI;-begivenheder virkelig kommer ind i &arts;. </para> + +<para +>Når en MIDI_DEBUG kører, udskriver &artsserver; linjer såsom: </para> + +<screen +><computeroutput +>201 100753.837585 on 0 42 127</computeroutput +></screen> + +<screen +><computeroutput +>202 101323.128355 off 0 42</computeroutput +></screen> + +<para +>Den første linje fortæller at 100753 ms (dvs. 100 sekunder) efter MIDI_DEBUG startede, kom en &MIDI;-begivenhed "on" på kanal 0. Denne midi-begivenhed havde hastighed (lydstyrke) 127, den højest mulige. Næste linje viser midi-begivenhed da tasten blev sluppet. [HUSK: dette virker ikke for øjeblikket, få det til at virke, og gør det via &MIDI;-håndteringen]. </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 +>Dette laver et signal med en konstant værdi. </para> +<!-- TODO: this doesn't really belong in test, does it? --> +</sect3> +</sect2> + +<sect2 id="mcat-synth-osc-mod"> +<title +>Oscillation & 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 +>Oscillatorer i &arts; kræver ikke en frekvens som inddata, men i stedet en position i bølgen. Positionen skal være mellem 0 og 1, som i et standardobjekt Synth_WAVE_SIN oversættes til området 0 .. 2*Pi. For at oprette oscillerende værdier fra en frekvens, bruges et 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 +>Dette bruges til frekvensmodulering. Angiv frekvensen med indgangen frequency og put et andet signal til moduleringsindgangen. Indstil derefter modlevel til et eller andet, f.eks. 0,3. Frekvensen moduleres derefter med moduleringen. Prøv det. Virker godt hvis man tilføjer en tilbagekobling, hvilket betyder at man tager en kombination af det forsinkede uddatasignal fra Synth_FM_SOURCE (man skal sende det til en oscillator eftersom det kun virker som Synth_FREQUENCY) og et andet signal for at få et godt resultat. </para> + +<para +>Virker godt sammen med Synth_WAVE_SIN oscillatorer. </para> +</sect3> + +</sect2> + +<sect2 id="mcat-synth-waveforms"> +<title +>Bølgeformer</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 +>Sinusoscillator. Angiv et pos signal fra Synth_FREQUENCY eller Synth_FM_SOURCE som indsignal, og få en sinusbølge som udsignal. Signalet pos angiver positionen i bølgeformen, området 0 .. 1 afbildes til 0 .. 2*Pi internt. </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 +>Triangelbølgeoscillator. Angiv et pos signal fra Synth_FREQUENCY eller Synth_FM_SOURCE som indsignal, og få en triangelbølge som udsignal. Signalet pos angiver positionen i bølgeformen, området 0 .. 1 afbildes til 0 .. 2*Pi internt. Vær forsigtig. Indsignalet <emphasis +>skal</emphasis +> være i området 0 .. 1 for at udsignalet kan give et godt resultat. </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 +>Støjgenerator. Denne laver et tilfældigt signal mellem -1 og 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 +>Firkantbølgeoscillator. Angiv et pos signal fra Synth_FREQUENCY eller Synth_FM_SOURCE som indsignal, og få en firkantbølge som udsignal. Signalet pos angiver positionen i bølgeformen, området 0 .. 1 afbildes til 0 .. 2*Pi internt. Vær forsigtig. Indsignalet <emphasis +>skal</emphasis +> være i området 0 .. 1 for at udsignalet kan give et godt resultat. </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 +>Blød savtandsbølge, som ligner Synth_WAVE_TRI oscillatoren i udseende. Angiv et pos signal fra Synth_FREQUENCY eller Synth_FM_SOURCE som indsignal, og få en blød savtandsbølge som udsignal. Signalet pos angiver positionen i bølgeformen, området 0 .. 1 afbildes til 0 .. 2*Pi internt. Vær forsigtig. Indsignalen <emphasis +>skal</emphasis +> være i området 0 .. 1 for at udsignalet kan give et godt resultat. </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 +>Pulsoscillator. Dette modul ligner den rektangulære oscillator (Synth_WAVE_RECT), men det sørger for et indstilleligt op/ned-forhold, ved parameteren <emphasis +>dutycycle</emphasis +>. Angiv et pos signal fra Synth_FREQUENCY eller Synth_FM_SOURCE som indsignal, og få en pulsbølge som udsignal. Signalet pos angiver positionen i bølgeformen, området 0 .. 1 afbildes til 0 .. 2*Pi internt. Vær forsigtig. Indsignalet <emphasis +>skal</emphasis +> være i området 0 .. 1 for at udsignalet kan give et godt resultat. </para> +</sect3> +</sect2> +<sect2 id="mcat-synth-misc"> +<title +>Diverse</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 +>Dette modul reducerer det dynamiske omfang af et signal. Reduktion er for eksempel nyttigt for at kompensere for de store variationer i lydstyrke når nogen taler i en mikrofon. </para> + +<para +>Så snart inddataniveauet overstiger et vist niveau (tærskelen) så reduceres signalet. Den multiplicerer helt enkelt alt over tærskelen med en ratio, som skal være en værdi mellem 0 og 1. Tilsidst multipliceres hele signalet med uddatafaktoren. </para> + +<para +>Argumenterne attack og release forsinker starten og slutningen af reduktionen. Brug dette hvis du for eksempel stadigvæk vil høre den stærke begyndelse af en bastromme. Argumenterne angives i millisekunder, og en attack eller release på 0 ms er mulig, men kan resultere i en let støj. </para> + +</sect3> +</sect2> +</sect1> + +<sect1 id="visual-modules-reference"> +<title +>Reference til visuelle moduler</title> + +<para +>HUSK når visuelle moduler er "færdige". </para> +</sect1> + +</chapter> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/porting.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/porting.docbook new file mode 100644 index 00000000000..89f1d0789e4 --- /dev/null +++ b/tde-i18n-da/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 +>Overfør programmer til at passe sammen med &arts;</title> + +<sect1 id="using-artsdsp"> +<title +>Brug af &artsdsp;</title> + +<para +>Værktøjet &artsdsp;, <link linkend="artsdsp" +>tidligere beskrevet</link +>, tillader de fleste ældre lydprogrammer som taler direkte med lydenheder at virke rigtigt med &arts;. Programmer som er skrevet til at bruge Enlightenment Sound Daemon (<application +>esd</application +>) virker også i de fleste tilfælde ved at køre <application +>esd</application +> med &artsdsp;. </para> + +<para +>Dette giver en god løsning på kort sigt for at ændre eksisterende programmer til &kde;. Det tillader dog ikke programmet direkte at drage fordel af hele &arts;' kraftfulde funktioner, såsom at bruge moduler og andre multimedietyper end digitallyd. Hvis programmet gør mere end kun helt enkelt at afspille lydfiler, er det oftest bedre at tilføje indbygget støtte for &arts; i programmet. </para> + +<para +>At bruge &arts; betyder også at programmet ikke behøver gøre så meget arbejde - det kan drage fordel af funktioner i &arts; til at håndtere ting såsom kodning for forskellige mediaformater og kontrol af lydkort. </para> + +</sect1> + +<sect1 id="adding-native-arts-support"> +<title +>Tilføjelse af indbygget støtte for &arts;</title> + +<para +>Når du bruger &arts;, er der et antal forskellige <link linkend="arts-apis" +>programmeringsgrænseflader</link +> (<acronym +>API</acronym +>) at vælge blandt. Beslutningen om hvilket som skal bruges afhænger af et antal forskellige faktorer, blandt andet hvilken slags medietype der bruges (lyd, &MIDI;, lyd-CD, etc.), de funktioner der kræves af grænsefladen, og om programmet er skrevet i C++. I de fleste tilfælde bør valget være ganske klart baseret på de nødvendige funktioner. </para> + +<para +>For flytbarhed mellem platforme kan programmer som skal kunne køre i andre miljøer end &kde; ikke stole på at &arts; er tilgængeligt. At bruge en plugin-paradigme er en god måde at støtte forskellige multimediemiljøer. At lave et plugin-<acronym +>API</acronym +> åbent og dokumenteret (især for programmer uden adgang til kildekode) har også den fordel at en anden end programudvikleren kan implementere plugin til &arts;. </para> + +</sect1> + +</chapter> + diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/references.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/references.docbook new file mode 100644 index 00000000000..7e1dd77a275 --- /dev/null +++ b/tde-i18n-da/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 +>Referencer</title> + +<variablelist> + +<varlistentry> +<term +><ulink +url="http://multimedia.kde.org" +>http://multimedia.kde.org</ulink +></term> +<listitem> +<para +>Dette er den hoved-hjemmesiden for &kde;-relateret multimedieinformation. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><ulink +url="http://www.arts-project.org" +>http://www.arts-project.org</ulink +></term> +<listitem> +<para +>Dette er &arts;-projektets hjemmeside. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +>&kde; 2.0 udvikling</term> +<listitem> +<para +>Kapitel 14 i denne offentliggjorte bog dækker multimedie, inklusive &arts;. Den er tilgængelig på tryk eller på nettet med kommentarer på <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 +>Dette sted har en udtømmende liste over lyd- og &MIDI;-programmer for &Linux;. </para> +</listitem> +</varlistentry> + +</variablelist> + +</chapter> diff --git a/tde-i18n-da/docs/tdemultimedia/artsbuilder/tools.docbook b/tde-i18n-da/docs/tdemultimedia/artsbuilder/tools.docbook new file mode 100644 index 00000000000..d5ec657d4b5 --- /dev/null +++ b/tde-i18n-da/docs/tdemultimedia/artsbuilder/tools.docbook @@ -0,0 +1,1003 @@ +<!-- +<?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 +>&arts;-værktøjer</title> + +<para +>Et antal værktøjer levereres sammen med &arts; til at kontrollere og indrette dens opførsel. Du skal kende en smule til de fleste af disse værktøjer for at kunne bruge &arts; på en effektiv måde. Dette afsnit beskriver hvert af værktøjerne og deres kommandoflag. </para> + +<sect1 id="kde-control-center"> +<title +>&kcontrol;</title> + +<para +>Når man kør &arts; under &kde;, sørger &kcontrolcenter; for en gruppe af indstillinger i kategorien <guilabel +>Lyd</guilabel +>. Visse af disse bruges af &arts;. Man kan også tilknytte lyd til forskellige vinduehåndterings- og &kde;-begivenheder med dialogen <menuchoice +><guilabel +>Lyd</guilabel +><guilabel +>Systembekendtgørelser</guilabel +></menuchoice +>. Se håndbogen for &kcontrol; for mere information om hvordan dialogens indstillinger bruges. </para> + +</sect1> + +<sect1 id="artsd"> +<title +>&artsd;</title> + +<para +>Adgangen til lydkort kontrolleres af &artsd;, lydserveren for &arts;-dæmonen. Dette tillader at flere programmer samtidigt sender forespørgsler til serveren, hvor de kan blandes og afspilles. Uden en central lydserver ville et enkelt program som bruger en lydenhed forhindre andre programmer i at bruge det. </para> + +<para +>For at bruge &arts; skal der være en og kun en kopi af &artsd; som kører. Den startes typisk når &kde; startes hvis dette er aktiveret i &kcontrol;'s <guilabel +>Lydserver</guilabel +>-modul. </para> + +<para +>Programmet accepterer følgende flag:</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 +>lydmetode</replaceable +></option +> <option +>-r <replaceable +>samplingrate</replaceable +></option +> <option +>-b <replaceable +>bit</replaceable +></option +> <option +>-d</option +> <option +>-D <replaceable +>enhedsnavn</replaceable +></option +> <option +>-F <replaceable +>fragmenter</replaceable +></option +> <option +>-S <replaceable +>størrelse</replaceable +></option +> <option +>-s <replaceable +>sekunder</replaceable +></option +> <option +>-m <replaceable +>programnavn</replaceable +></option +> </group +> <group choice="opt" +> <option +>-h</option +> <option +>-A</option +> <option +>-v</option +> <option +>-l <replaceable +>niveau</replaceable +></option +> </group +> </cmdsynopsis> + +<variablelist +><varlistentry> +<term +><option +>-r <replaceable +>samplingrate</replaceable +></option +></term> +<listitem> +<para +>Indstil samplingrate som skal bruges.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-h</option +></term> +<listitem> +<para +>Vis kommandobrug.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-n</option +></term> +<listitem> +<para +>Aktivér netværkstransparens.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-p <replaceable +>port</replaceable +></option> +</term> +<listitem> +<para +>Sæt <acronym +>TCP</acronym +>-port som skal bruges (forudsætter <option +>-n</option +>).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-u</option +></term> +<listitem> +<para +>Offentlig, ingen godkendelse (farligt).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-d</option +></term> +<listitem> +<para +>Aktivér fuld duplex.</para> +</listitem> +</varlistentry> +<varlistentry> +<term +><option +>-D <replaceable +>enhedsnavn</replaceable +></option +></term> +<listitem> +<para +>Angiv lydenhed (almindeligvis <filename +>/dev/dsp</filename +>).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-F <replaceable +>fragmenter</replaceable +></option +></term> +<listitem> +<para +>Sæt antal fragmenter.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-S <replaceable +>størrelse</replaceable +></option +></term> +<listitem> +<para +>Sæt fragmentstørrelse i byte.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-s <replaceable +>sekunder</replaceable +></option +></term> +<listitem> +<para +>Indstil forsinkelsen før autosuspendér aktiveres i sekunder. Værdien nul lukker af for autosuspendér.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-m <replaceable +>programnavn</replaceable +></option +></term> +<listitem> +<para +>Angiv navnet på et program som bruges til at vise fejl, advarsler og informationsmeddelelser. Hvis du kører KDE kan du bruge værktøjet <application +>artsmessage</application +> til dette.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-N</option +></term> +<listitem> +<para +>Forøg størrelsen af netværksbufferne til en værdi som er passende til at køre med et 10 Mbps lokalt netværk. Dette er det samme som at bruge flaget -w 5 (se nedenfor). </para> +</listitem> +</varlistentry> +<varlistentry> +<term +><option +>-w <replaceable +>n</replaceable +></option +></term> +<listitem> +<para +>Når <application +>artsd</application +> køres via en netværkstilslutning til en anden værtsmaskine vil man ofte bruge en stor buffer for at undgå pauser. aRts foreslår en minimal bufferstørrelse for programmer. Uden denne valgmulighed baserer den standardstørrelsen på fragmentstørrelsen * antal fragmenter. Med dette tilvalg kan man øge størrelsen fra standardstørrelsen med en faktor <replaceable +>n</replaceable +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-l <replaceable +>niveau</replaceable +></option +></term> +<listitem> +<para +>Indstil informationsniveau: 3 (tavs), 2 (advarsler), 1 (info), 0 (fejlsøgning).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-v</option +></term> +<listitem> +<para +>Vis versionsniveau.</para> +</listitem> +</varlistentry> + +</variablelist> + +<para +>I de fleste tilfælde er det nok kun at køre &artsd;. </para> +</sect1> + +<sect1 id="artswrapper"> +<title +>&artswrapper;</title> + +<para +>For at give gode realtidsegenskaber køres &artsd; oftest som en realtidsproces (på platforme hvor realtidsprioriteter understøttes). Dette kræver <systemitem class="username" +>root</systemitem +>-rettigheder, så for at minimere sikkerhedsproblemerne, kan &artsd; startes med det lille omsluttende program &artswrapper; som helt enkelt skifter til realtidsprioritet (mens det kører som <systemitem class="username" +>root</systemitem +>) og derefter starter &artsd; som en anden bruger end <systemitem class="username" +>root</systemitem +>. </para> + +<para +>Hvis du gør &artswrapper; SUID <systemitem class="username" +>root</systemitem +>, kommer det formodentlig til at forbedre kvaliteten af lydgengivningen ved at reducere huller i musikken. Dog øges også risikoen for at en fejl i koden, eller en ondsindet bruger kan få maskinen til at bryde sammen eller skade den på anden måde. Desuden kan det at prioritere høj lydkvalitet på flerbrugermaskiner forårsage forringet ydelse for brugere som forsøger at bruge maskinen på en <quote +>produktiv</quote +> måde.</para> + +</sect1> + +<sect1 id="artsshell"> +<title +>&artsshell;</title> + +<para +>Kommandoen &artsshell; er beregnet som et værktøj til at udføre diverse funktioner som hører sammen med lydserveren. Formodentlig vil værktøjet blive udvidet med nye kommandoer i fremtiden (se kommentarerne i kildekoden for nogle idéer). </para> + +<para +>Kommandoen accepterer følgende 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 [flag] <replaceable +>kommando</replaceable +> [<replaceable +>kommandotilvalg</replaceable +>] </para> + +<para +>Følgende flag understøttes: </para> + +<variablelist> + +<varlistentry> +<term +><option +>-q</option +></term> +<listitem> +<para +>Undertryk al udskrift.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-h</option +></term> +<listitem> +<para +>Vis kommandobrug.</para> +</listitem> +</varlistentry> + +</variablelist> + +<para +>Følgende kommandoer understøttes:</para> + +<variablelist> + +<varlistentry> +<term +><option +>suspend</option +></term> +<listitem> +<para +>Suspendér lydserveren. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>status</option +></term> +<listitem> +<para +>Vis statusinformation for lydserveren.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>terminate</option +></term> +<listitem> +<para +>Afslut lydserveren. Dette kan forvirre og/eller forårsage sammenbrud for programmer som for øjeblikket bruger den. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>autosuspend</option +> <parameter +>sekunder</parameter +></term> +<listitem> +<para +>Indstil forsinkelsen for aktivering af autosuspension til det angivne antal sekunder. Lydserveren vil blive suspenderet hvis den er inaktiv så længe. Værdien nul deaktiverer autosuspension. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>networkbuffers</option +> <parameter +>n</parameter +></term> +<listitem> +<para +>Indstiller størrelsen af netværksbufferne til en faktor <parameter +>n</parameter +> gange standardstørrelsen. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>volume</option +> [<replaceable +>volume</replaceable +>]</term> +<listitem> +<para +>Indstiller lydstyrkeskalering for lydserverens lyduddata. Parameteren <replaceable +>volume</replaceable +> er et decimaltal. Uden parameter vises den nuværende lydstyrke. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>stereoeffect liste</option +></term> +<listitem> +<para +>Vis alle tilgængelige stereoeffektmoduler.</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>stereoeffect insert [top|bottom]</option +> <replaceable +>navn</replaceable +></term> +<listitem> +<para +>Indsæt en stereoeffekt i stereoeffekt-stakken. Returnerer en identifikator som senere kan bruges til at fjerne den. Effekten kan installeres længst oppe eller længst nede (normalværdien).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>stereoeffect remove</option +> <replaceable +>id</replaceable +></term> +<listitem> +<para +>Fjerner stereoeffekten med identifikatoren <replaceable +>id</replaceable +> fra effektstakken.</para> +</listitem> +</varlistentry> + +</variablelist> + +</sect1> + +<sect1 id="artsplay"> +<title +><application +>artsplay</application +></title> + +<para +>Programmet <application +>artsplay</application +> er et enkelt værktøj til at afspille en lydfil. Det accepterer en enkelt parameter som svarer til navnet på lydfilen som sendes til lydserveren for at spilles. Lydfilen kan være en hvilken som helst almindelig lydfiltype, såsom <literal role="extension" +>wav</literal +> eller <literal role="extension" +>au</literal +>. Dette værktøj er godt til at prøve om lydserveren virker. Ved at køre to kommandoer parallelt eller i hurtig rækkefølge kan man demonstrere hvordan lydserveren blander mere end en lydkilde.</para> + +</sect1> + +<sect1 id="artsdsp"> +<title +><application +>artsdsp</application +></title> + +<para +>Lydserveren håndterer kun programmer som understøtter &arts;. Mange gamle programmer vil ønske at komme direkte til lydenheden. Kommandoen &artsdsp; sørger for en interimløsning som lader de fleste af disse programmer køre uforandrede. </para> + +<para +>Når et program køres med &artsdsp; fanges alle forsøg på at komme til lydenheden <filename class="devicefile" +>/dev/dsp</filename +> og forvandles til kald til &arts; programmeringsgrænseflade. Selv om enhedsemuleringen ikke er perfekt, så virker de fleste programmer på denne måde, omend med en vis forværring i ydelse og latenstid. </para> + +<para +>Kommandoen &artsdsp; følger formatet: </para> + +<!-- LW: FIX THIS --> +<para +>artsdsp [<replaceable +>flag</replaceable +>] <replaceable +>programargumenter</replaceable +> </para> + +<para +>Følgende flag genkendes: </para> + +<variablelist> + +<varlistentry> +<term +><option +>-h</option +>, <option +>--help</option +></term> +<listitem> +<para +>Vis kortfattet hjælp.</para> +</listitem> +</varlistentry> +<varlistentry> +<term +><option +>-n</option +> <option +>--name</option +> = <replaceable +>navn</replaceable +></term> +<listitem> +<para +>Brug <replaceable +>navn</replaceable +> til at identificere en afspiller for <command +>artsd</command +>.</para> + +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-m</option +> <option +>--mmap</option +></term> +<listitem> +<para +>Emulér hukommelsesafbildning (f.eks for <application +>Quake</application +>).</para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-v</option +> <option +>--verbose</option +></term> +<listitem> +<para +>Vis parametre.</para> +</listitem> +</varlistentry> + +</variablelist> + +<para +>Et typisk kald er: </para> + +<para> +<userinput +><command +>artsdsp</command +> <option +>-v</option +> <option +>-m</option +> <parameter +>realplay <replaceable +>song.mp3</replaceable +></parameter +></userinput> +</para> + +<para +>Visse programmer virker bedre med flaget <option +>--mmap</option +>. Lydenhedens funktioner er ikke alle fuldstændigt emulerede, men de fleste programmer skulle virke. Hvis du finder et som ikke gør det, så indsend en detaljeret fejlrapport så udviklerne kan ordne det. Igen, husk at dette er en midlertidig løsning og noget af en grim hurtigløsning. Den bedste løsning er at tilføje indbygget støtte for &arts; i programmerne. Hvis dit favoritlydprogram ikke har støtte for &arts;, så bed udviklerne om at sørge for det. </para> + +</sect1> + +<sect1 id="artscat"> +<title +><application +>artscat</application +></title> + +<para +>Dette er et enkelt værktøj til at sende rå lyddata til lydserveren. Man skal angive dataformatet (samplingsfrekvens, samplingsstørrelse og antal kanaler). Dette er formodentlig ikke et værktøj som man behøver bruge ofte, men det kan være bekvemt for testformål. Kommandosyntaksen er: </para> + +<!-- LW: FIX THIS --> + +<para +>artscat [ <replaceable +>flag</replaceable +> ] [ <replaceable +>filnavn</replaceable +> ] </para> + +<para +>Hvis intet filnavn angives læser programmet fra standardinddata. Følgende flag understøttes: </para> + +<variablelist> +<varlistentry> +<term +><option +>-r</option +> <parameter +>samplingsfrekvens</parameter +></term> +<listitem> +<para +>Sæt den samplingsfrekvens som bruges. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-b</option +> <parameter +>bit</parameter +></term> +<listitem> +<para +>Sæt samplingsstørrelse som bruges (8 eller 16). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-c</option +> <parameter +>kanaler</parameter +></term> +<listitem> +<para +>Sæt antal kanaler (1 eller 2). </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-h</option +></term> +<listitem> +<para +>Vis kommandobrug og afslut. </para> +</listitem> +</varlistentry> + +</variablelist> +</sect1> + +<sect1 id="artscontrol"> +<title +>&artscontrol;</title> + +<para +>Dette er et grafisk værktøj til at udføre et antal opgaver som hører sammen med lydserveren. Standardvinduet viser to lydstyrkeindikatorer og en skyder til at indstille den generelle afspilningslydstyrke. Fra menuen <guimenu +>Vis</guimenu +> kan du vælge andre funktioner: </para> + +<variablelist> + +<varlistentry> +<term +><guimenuitem +>FFT-omfang</guimenuitem +></term> +<listitem> +<para +>Åbner et vindue som viser en skærm med en realtidsspektrumanalysator. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>Lydhåndtering</guimenuitem +></term> +<listitem> +<para +>Viser aktive lydkilder og lader dig forbinde dem til alle tilgængelige busser. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>aRts status</guimenuitem +></term> +<listitem> +<para +>Viser om lydserveren kører og om realtidsskemalægning bruges. Angiver når serveren vil autosuspendere og tillader dig at suspendere med det samme. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>Midihåndtering</guimenuitem +></term> +<listitem> +<para +>Viser aktive &MIDI; ind- og udgange og tillader dig at lave forbindelser [HUSK: virker dette endnu? Behøver flere detaljer]. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>FreeVerb</guimenuitem +></term> +<listitem> +<para +>Tilslutter en FreeVerb efterklangseffekt til stakken af &arts; udskriftseffekter og lader dig kontrollere lydeffektindstillingerne grafisk. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><guimenuitem +>Led-lignende lydstyrkevisning</guimenuitem +></term> +<listitem> +<para +>Ændrer lydstyrkeindikatorerne i hovedvinduet til at bruge et visningsformat med farvede lysdioder i stedet for bjælker. </para> +</listitem> +</varlistentry> + +</variablelist> + +</sect1> + +<sect1 id="artsc-config"> +<title +><application +>artsc-config</application +></title> + +<para +>Dette værktøj er der for at hjælpe udviklere som bruger C-<acronym +>API</acronym +> i &arts;. Det angiver de rigtige oversætter- og linkflag som behøves når man kompilerer og linker med &arts;. Det er beregnet til at bruges i make-filer for at hjælpe til med flytbarhed. Kommandoen accepterer tre flag: </para> + +<variablelist> +<varlistentry> +<term +><option +>--cflags</option +></term> +<listitem> +<para +>Viser oversætterflag som behøves når man kompilerer med &arts; C-<acronym +>API</acronym +>. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>--libs</option +></term> +<listitem> +<para +>Viser linkerflag som behøves når man linker med &arts; C-<acronym +>API</acronym +>. </para> +</listitem> +</varlistentry> +<varlistentry> +<term +><acronym +>---version</acronym +></term> +<listitem> +<para +>Viser versionen af kommandoen <command +>artsc-config</command +>. </para> +</listitem> +</varlistentry> +</variablelist> + +<para +>Typisk udskrift fra kommandoen vises nedenfor:</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 +>Man skal kunne bruge dette værktøj i en make-fil med en regel såsom: </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 +>Kommandoen &mcopidl; er &IDL;-fil oversætteren for &MCOP;, multimedia-kommunikationsprotokollen som bruges af &arts;. Grænseflader i &arts; defineres med &IDL;, et sproguafhængig grænsefladesdefinitionssprog. Værktøjet &mcopidl; accepterer en &IDL;-fil som inddata og laver C++ deklarations- og kildekodefiler for en klasse som implementerer grænsefladen. Kommandoen accepterer følgende syntaks: </para> + +<!-- LW: FIX THIS --> + +<para +>mcopidl [ <replaceable +>flag</replaceable +> ] <replaceable +>filnavn</replaceable +> </para> + +<para +>Gyldige flag er:</para> +<variablelist> +<varlistentry> +<term +><option +>-I</option +> <parameter +>mappe</parameter +></term> +<listitem> +<para +>Søg i <parameter +>mappe</parameter +> efter deklarationsfiler. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-e</option +> <parameter +>navn</parameter +></term> +<listitem> +<para +>Spring over en struct, grænseflade eller nummereringstypen <parameter +>navn</parameter +> ved kodegenerering. </para> +</listitem> +</varlistentry> + +<varlistentry> +<term +><option +>-t</option +></term> +<listitem> +<para +>Opret også <literal role="extension" +>.mcoptype</literal +>/<literal role="extension" +>.mcopclass</literal +> filer som indeholder typeinformation for &IDL;-filen. </para> +</listitem> +</varlistentry> +</variablelist> + +<para +>Mere information om &MCOP; og &IDL; findes i afsnittet <link linkend="interfaces" +>Grænseflader og &IDL;</link +>. </para> + +</sect1> + +</chapter> |