From 9b58d35185905f8334142bf4988cb784e993aea7 Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Mon, 21 Nov 2011 02:23:03 -0600 Subject: Initial import of extracted KDE i18n tarballs --- .../docs/kdemultimedia/artsbuilder/Makefile.am | 4 + .../docs/kdemultimedia/artsbuilder/Makefile.in | 635 +++++++ .../docs/kdemultimedia/artsbuilder/apis.docbook | 434 +++++ .../kdemultimedia/artsbuilder/artsbuilder.docbook | 917 +++++++++ .../docs/kdemultimedia/artsbuilder/detail.docbook | 1388 ++++++++++++++ .../kdemultimedia/artsbuilder/digitalaudio.docbook | 16 + .../docs/kdemultimedia/artsbuilder/faq.docbook | 1312 +++++++++++++ .../docs/kdemultimedia/artsbuilder/future.docbook | 401 ++++ .../kdemultimedia/artsbuilder/glossary.docbook | 177 ++ .../docs/kdemultimedia/artsbuilder/gui.docbook | 29 + .../docs/kdemultimedia/artsbuilder/helping.docbook | 237 +++ .../docs/kdemultimedia/artsbuilder/index.cache.bz2 | Bin 0 -> 83020 bytes .../docs/kdemultimedia/artsbuilder/index.docbook | 417 +++++ .../docs/kdemultimedia/artsbuilder/mcop.docbook | 1974 ++++++++++++++++++++ .../docs/kdemultimedia/artsbuilder/midi.docbook | 524 ++++++ .../kdemultimedia/artsbuilder/midiintro.docbook | 16 + .../docs/kdemultimedia/artsbuilder/modules.docbook | 1329 +++++++++++++ .../docs/kdemultimedia/artsbuilder/porting.docbook | 52 + .../kdemultimedia/artsbuilder/references.docbook | 61 + .../docs/kdemultimedia/artsbuilder/tools.docbook | 1007 ++++++++++ 20 files changed, 10930 insertions(+) create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/Makefile.am create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/Makefile.in create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/apis.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/artsbuilder.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/detail.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/digitalaudio.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/faq.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/future.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/glossary.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/gui.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/helping.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/index.cache.bz2 create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/index.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/mcop.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/midi.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/midiintro.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/modules.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/porting.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/references.docbook create mode 100644 tde-i18n-pt/docs/kdemultimedia/artsbuilder/tools.docbook (limited to 'tde-i18n-pt/docs/kdemultimedia/artsbuilder') diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/Makefile.am b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/Makefile.am new file mode 100644 index 00000000000..6869837a64a --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/Makefile.am @@ -0,0 +1,4 @@ +KDE_LANG = pt +SUBDIRS = $(AUTODIRS) +KDE_DOCS = AUTO +KDE_MANS = AUTO diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/Makefile.in b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/Makefile.in new file mode 100644 index 00000000000..9ee6b24504b --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/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/kdemultimedia/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@ +kdeinitdir = @kdeinitdir@ +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 = pt +#>- 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/kdemultimedia/artsbuilder/Makefile'; \ +#>- cd $(top_srcdir) && \ +#>- $(AUTOMAKE) --gnu docs/kdemultimedia/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/kdemultimedia/artsbuilder/Makefile'; \ + cd $(top_srcdir) && \ + $(AUTOMAKE) --gnu docs/kdemultimedia/artsbuilder/Makefile + cd $(top_srcdir) && perl ../scripts/admin/am_edit -p../scripts/admin docs/kdemultimedia/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/kdemultimedia/artsbuilder/Makefile'; \ + cd $(top_srcdir) && \ + $(AUTOMAKE) --gnu docs/kdemultimedia/artsbuilder/Makefile + cd $(top_srcdir) && perl ../scripts/admin/am_edit -p../scripts/admin docs/kdemultimedia/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-pt/docs/kdemultimedia/artsbuilder/apis.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/apis.docbook new file mode 100644 index 00000000000..0eacdd0588f --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/apis.docbook @@ -0,0 +1,434 @@ + + + +Interfaces de Programação de Aplicações do &arts; + + +Introdução +O aRts não é apenas um pedaço de 'software', também fornece uma variedade de APIs para uma variedade de fins. Nesta secção, será dada uma "ideia geral", uma breve apresentação do que essas APIs supostamente deverão fazer e como interagem. + +Existe uma distinção importante a fazer: a maioria das APIs são independentes da linguagem e da localização dado que são especificadas no mcopidl. Isto é, você pode basicamente usar os serviços que elas oferecem a partir de qualquer linguagem, implementá-las em qualquer linguagem e não terá de se preocupar se está a falar com objectos locais ou remotos. Aqui está uma lista destes, em primeiro lugar: + + + + +core.idl + As definições básicas que formam o núcleo da funcionalidade do MCOP, como por exemplo o próprio protocolo, as definições do objecto, o mediador, o sistema de fluxo e assim por diante. + + + + +artsflow.idl + + Estes contêm o sistema de fluxo que você irá usar para se ligar às sequências de áudio, a definição do Arts::SynthModule que é a base de qualquer interface que emita sequências multimédia e, finalmente, alguns objectos de áudio úteis + + + + +kmedia2.idl + + + Aqui está definido um objecto que poderá reproduzir conteúdos multimédia, o Arts::PlayObject. Os leitores multimédia como o 'noatun', o reprodutor multimédia serão capazes de reproduzir qualquer conteúdo multimédia para o qual exista um PlayObject. Por isso, faz sentido implementar os PlayObjects para os vários formatos (como o MP3, o vídeo MPEG, MIDI, WAV, ...) nessa base, e já existem alguns de facto. + + + + +soundserver.idl + + Aqui está definida uma interface para o servidor de som do sistema, o 'artsd'. A interface chama-se Arts::SoundServer, e implementa alguma funcionalidade como a aceitação de sequências multimédia da rede, a reprodução de amostras, a criação de outros objectos personalizados do aRts, e assim por diante. A transparência da rede está implícita devido à utilização do MCOP (como em tudo o resto, de facto). + + + + +artsbuilder.idl + Este módulo define a funcionalidade básica do grafo de fluxo, isto é, a combinação de objectos mais simples de modo a criar objectos mais complexos, definindo para tal um grafo com eles. Ele define a interface básica Arts::StructureDesc, a Arts::ModuleDesc e a Arts::PortDesc, as quais contêm uma descrição de uma estrutura, um módulo e um porto. Existe também uma forma de obter uma "rede viva de objectos" com essas descrições de ligações e valores, usando uma 'factory' (fábrica). + + + + +artsmidi.idl + + Este módulo define a funcionalidade básica de MIDI, com os objectos que produzem os eventos do MIDI, o que é um evento do MIDI, um Arts::MidiManager para se ligar aos produtores e aos consumidores de eventos MIDI, e assim por diante. Como sempre, está implícita a transparência da rede. + + + + +artsmodules.idl + Aqui existem vários filtros, osciladores, efeitos, atrasos adicionais, entre outros objectos, sendo tudo necessário para o processamento útil de sinal, e para criar instrumentos e efeitos complexos a partir destes blocos de construção básicos. + + + + +artsgui.idl + + Este preocupa-se com os objectos visuais. Ele define o tipo básico Arts::Widget a partir do qual todos os módulos gráficos derivam. Isto irá produzir uma independência da plataforma e .... edição gráfica visual, assim como a noção de GUIs com capacidades de serialização. Do mesmo modo, dado que os elementos gráficos têm atributos normais, os seus valores poderão ser ligados com facilidade a alguns módulos de processamento de sinal (isto é, o valor de uma barra deslizante à frequência de corte de um filtro). Como sempre: transparência de rede. + + + + +Sempre que possível, o próprio aRts está implementado usando a IDL. Por outro lado, existem algumas APIs específicas da linguagem, usando tanto C++ ou C normal. É normalmente aconselhado usar as interfaces IDL sempre que possível, usando as outras APIs quando for mesmo necessário. Aqui está uma lista das APIs específicas da linguagem: + + + + +KNotify, KAudioPlayer (incluídos na 'libkdecore') + + Estas são APIs do KDE de conveniência para os casos simples e comuns, onde você apenas deseja tocar uma amostra. As APIs são em C++ normal, optimizado para o Qt/KDE, e o mais simples possíveis. + + + + +libartsc + Uma interface em C simples para o servidor de som. Muito útil ao transformar aplicações legadas. + + + + +libmcop + + Aqui é onde acontece toda a mágica do MCOP. A biblioteca contém as noções básicas que precisa de saber para criar uma aplicação de MCOP simples, o 'dispatcher', os temporizadores, a gestão de E/S e os pormenores internos que fazem o protocolo do MCOP funcionar em si. + + + + +libartsflow + Para além da implementação do 'artsflow.idl', contém alguns utilitários como a conversão da taxa de amostragem. + + + + +libqiomanager + + A integração do MCOP no ciclo de eventos do Qt, quando você cria aplicações do Qt com o MCOP. + + + + + + + + + +knotify +Ainda não escrito + + + +kaudioplayer +Ainda não escrito + + + +libkmid +Ainda não escrito + + + +kmedia2 +Ainda não escrito + + + +servidor de som +Ainda não escrito + + + +artsflow +Ainda não escrito + + + +<acronym +>API</acronym +> do C + + +Introdução + +A API de C do &arts; foi desenhada para tornar simples a criação e a transformação de aplicações simples de C para tirarem partido do servidor de som &arts;. Ele contém algumas funcionalidades de difusão (o envio de sequências de amostras para o artsd), quer bloqueantes quer não-bloqueantes). Para a maioria das aplicações, você simplesmente irá retirar as poucas chamadas de sistema que lidam com o seu dispositivo de áudio e substitui-las com as chamadas de &arts; apropriadas. + +Foram feitas duas passagens como prova da teoria: o mpg123 e o quake. Você poderá obter as correcções aqui. Sinta-se à vontade para enviar as suas próprias alterações para os responsáveis pelo &arts; ou pelos pacotes de 'software' multimédia, de modo a que possam integrar o suporte do &arts; no seu código. + + + + +Percurso Rápido + +O envio de áudio para o servidor de som com a API é bastante simples: + +incluir o ficheiro da API usando o #include <artsc.h> +inicializar a API com o arts_init() +criar um canal com o arts_play_stream() +configurar os parâmetros específicos com o arts_stream_set() +escrever os dados das amostras para o canal com o arts_write() +fechar o canal com o arts_close_stream() +libertar a API com o arts_free() + + +Aqui está um pequeno programa de exemplo que ilustra isto: + +#include <stdio.h> +#include <artsc.h> +int main() +{ + arts_stream_t canal; + char dados[8192]; + int bytes; + int erro; + + erro = arts_init(); + if (erro < 0) + { + fprintf(stderr, "erro do arts_init: %s\n", arts_error_text(erro)); + return 1; + } + + canal = arts_play_stream(44100, 16, 2, "testeartsc"); + + while((bytes = fread(dados, 1, 8192, stdin)) > 0) + { + erro = arts_write(canal, dados, bytes); + if(erro < 0) + { + fprintf(stderr, "erro do arts_write: %s\n", arts_error_text(erro)); + return 1; + } + } + + arts_close_stream(canal); + arts_free(); + + return 0; +} + + + + +Compilar e Gerar o Executável: <application +>artsc-config</application +> + +Para compilar e gerar os binários com facilidade, usando a API de C do &arts;, o utilitário artsc-config é fornecido e indica quais as bibliotecas que você precisa para compilar e onde se encontram os ficheiros de inclusão. É invocado com o comando + +artsc-config + + +para saber quais as bibliotecas e + +artsc-config + + +para saber quais as opções adicionais do compilador de C. O exemplo acima poderia ter sido compilado com a linha de comandos: + +cc + +cc + + + + + +Referência das Bibliotecas + +[TODO: gerar a documentação do artsc.h com o 'kdoc'] + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/artsbuilder.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/artsbuilder.docbook new file mode 100644 index 00000000000..fd49688924d --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/artsbuilder.docbook @@ -0,0 +1,917 @@ + +&arts-builder; + + +Introdução + +Primeiro que tudo, ao tentar correr o &arts-builder; , você deverá correr também o servidor de som (o &artsd;). Normalmente, quando você usa o &kde; 2.1, este já deverá ser o caso. Se não for, você poderá configurar o arranque automático do servidor de som no &kcontrol; em SomServidor de Som. + +Quando você está a executar o &arts;, ele corre sempre módulos pequenos. O &arts-builder; é uma ferramenta para criar estruturas novas a partir de pequenos módulos interligados. Você simplesmente carrega os módulos para dentro da grelha. Para o fazer, escolha-os no menu Módulos, e carregue então algures no avião verde-e-cinzento. + +Os módulos normalmente têm portos (onde normalmente entram e saem os sinais de áudio). Para ligar dois portos, carregue no primeiro, o que normalmente faz com que ele fique laranja, e carregue depois no segundo. Você poderá ligar apenas um porto de entrada (na parte de cima) com um porto de saída (na parte inferior de um módulo). Se você quiser atribuir um valor fixo a um porto (ou desligá-lo), faça duplo-click no mesmo. + + + + +Tutorial + + +Passo 1 + +Inicie o &arts-builder;. + +Você precisa de um módulo Synth_AMAN_PLAY para ouvir a saída que está a criar. Por isso crie um módulo Synth_AMAN_PLAY, seleccionando-o em Módulos Síntese E/S de Som Synth_AMAN_PLAY e carregue no espaço em branco do módulo. Coloque-o por baixo da quinta linha ou algo do género, porque serão adicionadas aqui algumas coisas. + +O módulo irá ter um parâmetro title ou título (o porto do lado esquerdo), um autoRestoreID (ao lado do porto do lado esquerdo) para o encontrar. Para os preencher, faça duplo-click nesses portos, seleccione um valor constante e escreva tutorial no campo de texto. Carregue em OK para aplicar. + +Seleccione FicheiroExecutar a estrutura . Você não irá ouvir absolutamente nada. O módulo de reprodução ainda necessita de uma entrada... ;) Se você tiver 'ouvido' o silêncio um pouco, carregue em OK e vá para o Passo 2 + + + +Passo 2 + +Crie um módulo Synth_WAVE_SIN (em Módulos Síntese Formas de onda) e coloque-o por cima do módulo Synth_AMAN_PLAY. (Deixe um espaço de uma linha entre eles). + +Como poderá ver, ele produz algum resultado, mas necessita de um pos como entrada. Primeiro, vai-se ligar a saída ao altifalante. Carregue no porto out (saída) do módulo Synth_WAVE_SIN e depois no porto left (esquerda) do Synth_AMAN_PLAY. Pronto, você acabou de ligar dois módulos. + +Todos os osciladores no &arts; não precisam de uma frequência à entrada, mas si de uma posição na onda. A posição deverá ser entre 0 e 1, o que se mapeia num objecto normal do Synth_WAVE_SIN no intervalo 0..2*pi. Para gerar os valores oscilantes para uma frequência, é usado um módulo Synth_FREQUENCY. + +Crie um módulo Synth_FREQUENCY (em Módulos Síntese Oscilação & Modulação ) e ligue a sua saída pos na entrada pos do seu Synth_WAVE_SIN. Indique o porto 'frequency' (frequência) do gerador FREQUENCY com um valor constante 440. + + +Seleccione o FicheiroExecutar a estrutura. Irá ouvir uma onda sinusoidal de 440 Hz num dos seus altifalantes. Se você a tiver ouvido durante algum tempo, carregue em OK e vá para o Passo 3. + + + + +Passo 3 + +OK, seria melhor se você ouvir a onda sinusoidal em ambos os altifalantes. Ligue o porto 'right' (direita) do Synth_PLAY ao 'outvalue' (saída) do Synth_WAVE_SIN. + +Crie um objecto Synth_SEQUENCE (em Módulos SínteseMIDI & Sequenciação). Dever-se-á encontrar no topo do ecrã. Se precisar de mais espaço, você poderá mover os outros módulos, seleccionando-os (para seleccionar vários módulos use o &Shift;) e arrastando-os. + +Agora ligue a saída 'frequency' (frequência) do Synth_SEQUENCE à entrada 'frequency' do módulo Synth_FREQUENCY. Depois, indique a velocidade da sequência como um valor constante 0,13 (o 'speed' ou velocidade é o porto mais à esquerda). + +Agora vá ao porto mais à direita (o 'sequence' ou sequência) do Synth_SEQUENCE e escreva como valor constante A-3;C-4;E-4;C-4;; isto corresponde a uma sequência. Poderá ver mais sobre isto na Referência do Módulo. + + +O Synth_SEQUENCE necessita mesmo de uma sequência e da sua velocidade. Sem isto, você irá obter provavelmente alguns estoiros. + + +Seleccione o FicheiroExecutar a Estrutura. Você irá ver uma sequência bonita a tocar. Se gostou da sensação, carregue em OK e vá para o Passo 4. + + + +Passo 4 + +Crie um módulo Synth_PSCALE (em Módulos Síntese Envelopes ). Desligue o 'outvalue' (saída) da onda sinusoidal, fazendo duplo-click nela e escolher a opção não ligado. Ligue + + +O valor de saída do SIN ao valor de entrada do PSCALE + + +O valor de saída do PSCALE à esquerda do AMAN_PLAY + + +O valor de saída do PSCALE à direita do AMAN_PLAY + + +A posição do SEQUENCE à posição do PSCALE + + + +Finalmente, configure o topo do PSCALE para um valor qualquer, por exemplo 0,1. + +Como é que funciona então: o Synth_SEQUENCE dá informações adicionais sobre a posição da nota que está a tocar de momento, onde o 0 significa que começou agora e 1 significa que terminou. O módulo Synth_PSCALE irá ajustar o facto de escala do canal de áudio que é passado por ele, desde um volume 0 (silêncio) até 1 (volume original), voltando outra vez a 0 (silêncio), de acordo com a posição. A posição onde o pico deverá ocorrer poderá ser indicada no 'pos'. Um valor igual a 0,1 significa que, depois de ter tocado 10% da nota, o volume terá atingido o seu máximo, começando a decair a partir daí. + + +Seleccione FicheiroExecutar a Estrutura. Você irá ouvir uma sequência bonita a tostou da situação, carregue em OK e vá para o Passo 5. + + + + +Passo 5: Começar a emitir os dados ;) + +Inicie outro &arts-builder; + +Coloque um Synth_AMAN_PLAY nele e configure-o para um nome aceitável. Coloque um Synth_BUS_DOWNLINK nele e: + + + +Configure o barramento do Synth_BUS_DOWNLINK para áudio (isto é apenas um nome, chame-lhe 'manel' se quiser) + + +Ligue a esquerda do Synth_BUS_DOWNLINK à esquerda do Synth_AMAN_PLAY + + +Ligue a direita do Synth_BUS_DOWNLINK à direita do Synth_AMAN_PLAY + + + +Comece a executar a estrutura. Como seria de esperar, não ouve nada, ... ainda. + +Volte à estrutura com as coisas do Synth_WAVE_SIN e substitua o módulo Synth_AMAN_PLAY module por um Synth_BUS_UPLINK, configurando o seu nome para 'áudio' (ou 'manel', se preferir); os módulos poderão ser removidos se os seleccionar e escolher Editar Remover no menu (ou carregando na tecla Del). + +Carregue em Ficheiro Executar a estrutura. Irá ouvir a sequência com as notas em escala, transportadas no barramento. + +Se quiser saber porque é que algo como isto poderá de facto ser útil, carregue em OK (no &arts-builder; que está a executar o bloco do Synth_SEQUENCE; você poderá deixar o outro a correr) e ir para o Passo 6. + + + +Passo 6: Apontar para utilizadores avançados + +Escolha a estrutura FicheiroMudar o nome no menu do 'artsbuilder' que contém as coisas do Synth_SEQUENCE, chamando-lhe de 'tutorial'. Carregue em OK. + +Seleccione Ficheiro Gravar + +Inicie ainda mais outro &arts-builder; e escolha FicheiroAbrir , e carregar o tutorial de novo. + +Agora poderá seleccionar FicheiroExecutar a estrutura em ambos os &arts-builder;s que têm estrutura. Você irá ouvir agora duas vezes a mesma coisa. Dependendo da altura em que os inicia, irá soar melhor ou pior. + +Outra coisa boa para fazer nesta altura é: iniciar o &noatun; e tocar um mp3 qualquer. Inicie o &artscontrol;. Vá a VerVer o gestor de áudio. O que irá ver será o &noatun; e a sua estrutura de reprodução tutorial a tocar algo. Uma coisa interessante que poderá fazer é o seguinte: faça duplo-click no &noatun;. Irá agora obter uma lista com os barramentos disponíveis. Verá também que poderá indicar ao &noatun; para enviar a sua saída através do barramento de áudio que a sua estrutura do tutorial oferece. + + + +Passo 7: Síntese MIDI + +Finalmente, você deverá agora ser capaz de transformar a sua onda sinusoidal num instrumento real. Só faz sentido se você tiver algo útil que possa enviar eventos de &MIDI; para o &arts;. Será descrito aqui como você poderá usar um teclado externo qualquer, mas uma solução de sequenciação MIDI como o &brahms; irá funcionar da mesma forma. + +Primeiro que tudo, limpe o seu ecrã até que você tenha apenas um &arts-builder; com a estrutura da onda sinusoidal aberta (mas não em execução). De seguida, vá três vezes a Portos Criar sinal de áudio IN, e outras três a Portos Criar sinal de áudio OUT. Coloque esses portos algures. + +Finalmente, vá a Portos Mudar as posições e nomes e chame aos portos 'frequency' (frequência), 'velocity' (velocidade), 'pressed' (carregado), 'left' (esquerdo), 'right' (direito), 'done' (pronto). + +Finalmente, você poderá remover o módulo Synth_SEQUENCE e ligar o porto de entrada 'frequency' (frequência) da estrutura ao porto 'frequency' do Synth_FREQUENCY. Hm... Mas o que fazer com o 'pos'? Não existe isso, porque não há nenhum algoritmo no mundo onde você possa prever quando é que o utilizador solta a nota que acabou de carregar no teclado MIDI. Por isso, existe um parâmetro 'pressed' (carregado) que indica se o utilizador ainda tem a tecla pressionada ou não ('pressed' = 1: a tecla ainda está carregada, 'pressed' = 0: tecla solta) + +Isto significa que o objecto Synth_PSCALE também precisa de ser substituído agora. Ligue um Synth_ENVELOPE_ADSR em alternativa (em Módulos Síntese Envelopes ). Ligue: + + + +A entrada 'pressed' da estrutura ao 'active' (activo) do ADSR + + +O valor de saída do SIN ao valor de entrada do PSCALE + + +O valor de saída do ADSR à saída 'left' (esquerda) da estrutura + +O valor de saída do ADSR à saída 'right' (direita) da estrutura + + + +Configure os parâmetros 'attack' (ataque) igual a 0,1, 'decay' (decaimento) igual a 0,2, 'sustain' (sustentação) igual a 0,7 e 'release' (soltura) igual a 0,1. + +Outra coisa em que é preciso pensar é que a estrutura do instrumento precisa de saber de alguma forma quando é que está pronta para tocar e quando poderá ser limpa, porque caso contrário nunca seria interrompida, mesmo que a nota tivesse sido solta. Felizmente, o envelope do ADSR sabes quando não há mais nada para se ouvir, dado que ele iguala o sinal a zero nalgum ponto em que a nota foi solta. + +Isto é indicado ao pôr a saída 'done' (pronto) igual a 1. Por isso, ligue isto à saída 'done' da estrutura. A mesma será removida logo que o 'done' passe a 1. + +Mude o nome da sua estrutura para 'instrument_tutorial' (em Ficheiro Mudar o nome da estrutura. De seguida, grave-a usando o Gravar Como (o nome por omissão que é oferecido deverá ser agora igual a 'instrument_tutorial').Inicie o 'artscontrol' e vá a VerGestor de MIDI, escolhendo depois a opção AdicionarSaída MIDI de Síntese do aRts. Finalmente, você deverá ser capaz de seleccionar o seu instrumento de tutorial aqui. + +Abra um terminal e escreva midisend. Você irá ver que o midisend e o instrumento estão agora listados no gestor de &MIDI; do &arts;. Depois de seleccionar ambos e de carregar em Ligar, é tudo. Pegue no seu teclado e comece a tocar (obviamente, terá de estar ligado ao seu computador). + + + +Sugestões + +Agora você deverá ser capaz de trabalhar com o &arts;. Ficam aqui algumas dicas que você poderá tentar para melhorar com as suas estruturas: + + + +Tente usar outras coisas para além de uma onda sinusoidal. Quando ligar uma onda triangular, você irá pensar que o som não é grande coisa. Mas tente adicionar um filtro SHELVE_CUTOFF logo a seguir à onda triangular para cortar as frequências acima de uma dada frequência (tente algo do género de 1000 Hz, ou mesmo duas vezes a frequência de entrada ou igual à frequência de entrada+200Hz, ou qualquer outra coisa do género). + + +Tente usar mais do que um oscilador. O Synth_XFADE poderá ser usado para misturar dois sinais; use por outro lado o Synth_ADD para os adicionar. + + +Tente configurar as frequências dos osciladores para valores diferentes; isto dará umas oscilações engraçadas. + + +Experimente com mais do que um envelope. + + +Tente sintetizar os instrumentos com resultados diferentes do lado esquerdo e do direito. + + +Tente fazer o pós-processamento depois de sair da ligação de recepção do barramento. Você poderá misturar, por exemplo, uma versão atrasada do sinal ao sinal original para obter um efeito de eco. + + +Tente usar a opção 'velocity' (velocidade), a qual corresponde à força com que a nota foi carregada, e poderá também dizer 'volume'). O efeito especial consiste em não só modificar o volume do sinal resultante, mas também o som do instrumento (como por exemplo a frequência de corte). + + +... + + + +Se você criou algo engraçado, pense por favor em fornecê-lo à página Web do &arts; ou para ser incluído na próxima versão. + + + + + +Exemplos + +O &arts-builder; vem com vários exemplos, os quais poderão ser acedidos através da opção FicheiroAbrir um Exemplo... . Alguns deles estão na sua pasta correspondente, enquanto que outros (os quais não funcionam por uma razão qualquer na versão actual) são deixados na pasta 'todo'. +Os exemplos caem em várias categorias: + + + +Os exemplos autónomos que ilustram como usar cada um dos módulos incorporados do 'arts' (chamados example_*.arts). Estes tipicamente enviam um resultado qualquer para uma placa de som. + + + +Os instrumentos que são criados a partir de módulos de nível mais baixo (chamados de instrument_*.arts). Estes seguem uma convenção normal para os portos de entrada e saída para que possam ser usados no gestor de &MIDI; no &artscontrol;. + + + +Os modelos para criar novos módulos (denominados por template_*.arts). + + + +Os efeitos que poderão ser usados como blocos de construção reutilizáveis (chamados de effect_*.arts) [ tudo no 'todo' ] + + + +Os elementos de mistura usados para criar mesas de mistura, incluindo os controlos gráficos (chamados de mixer_element_*.arts). [ tudo no 'todo' ] + + + +Módulos diversos que não se encaixam em nenhuma das categorias acima. + + + + +Descrição Detalhada de Cada Módulo: + +example_stereo_beep.arts + +Gera uma onda sinusoidal de 440Hz no canal esquerdo e uma onda sinusoidal no canal direito, enviando o resultado para a saída da placa de som. Isto é referenciado na documentação do &arts;. + + + + +example_sine.arts + +Gera uma onda sinusoidal de 440 Hx. + + + + +example_pulse.arts + +Gera uma onda de impulsos de 440 Hz com um tempo de actividade de 20%. + + + + +example_softsaw.arts + +Gera uma onda de dente-de-serra de 440 Hz. + + + + +example_square.arts + +Gera uma onda quadrada de 440 Hz. + + + + +example_tri.arts + +Gera uma onda triangular de 440 Hz. + + + + +example_noise.arts + +Gera 'ruído branco'. + + + + +example_dtmf1.arts + +Gera um tom duplo, produzindo para tal ondas sinusoidais de 697 e 1209 Hz, ajustando a escala para 0,5 e adicionando-as em conjunto. Isto é o tom DTMF para o número "1" num teclado de telefone. + + + + +example_atan_saturate.arts + +Corre uma onda triangular com o filtro de saturação 'atan' (arco-tangente). + + + + +example_autopanner.arts + +Usa um deslocador automático para deslocar uma onda sinusoidal de 400 Hz entre os altifalantes esquerdo e direito a um ritmo de 2 Hz. + + + + +example_brickwall.arts + +Ajusta a escala de uma onda sinusoidal por um factor de 5 e passa-a por um limitador. + + + + +example_bus.arts + +Recebe de um barramento chamado Bus (Barramento) e envia para o barramento out_soundcard (saída da placa de som) com os canais esquerdo e direito invertidos. + + + + +example_cdelay.arts + +Recebe de um barramento chamado Delay (Atraso), envia o canal direito através de um atraso de 0,5 segundos e o esquerdo sem alterações. Você poderá usar o &artscontrol; para ligar o efeito a um reprodutor de som e observar os resultados. + + + + +example_delay.arts + +Este é o mesmo que o example_cdelay.arts mas usando o efeito de atraso. + + + + +example_capture_wav.arts + +Isto usa o Synth_CAPTURE_WAV para gravar uma onda sinusoidal de 400 Hz como um ficheiro WAV. Execute o módulo durante uns segundos e examine depois o ficheiro criado em /tmp. Você poderá tocar o ficheiro com um leitor multimédia como o noatun. + + + + +example_data.arts + +Isto usa o módulo Data (Dados) para gerar uma sequência constante com o valor 3 e envia-a para um módulo Debug (Depuração) que o mostra periodicamente. Também contém um módulo Nil (Nada), que ilustra como poderá ser usado para não fazer absolutamente nada. + + + + +example_adsr.arts + +Mostra como criar um único som de um instrumento com o módulo 'Envelope Adsr' (ADSR do Envelope), despoletado repetidamente por uma onda quadrada. + + + + +example_fm.arts + +Isto usa o módulo de Fonte FM para gerar uma onda sinusoidal de 440 Hz que é modulada na frequência a uma taxa de 5 Hz. + + + + +example_freeverb.arts + +Isto liga o efeito do Freeverb a partir do canal de recepção de um barramento a um canal de envio de outro barramento. Você poderá usar o &artscontrol; para ligar o efeito a um leitor de áudio e observar os resultados. + + + + +example_flanger.arts + +Isto implementa um efeito simples de 'flanger' (não parece funcionar ainda, no entanto). + + + + +example_moog.arts + +Esta estrutura combina os dois canais de um barramento num só, passando-o através do filtro VCF Moog, e envia o resultado para o barramento 'out_soundcard'. + + + + +example_pitch_shift.arts + +Esta estrutura passa o canal esquerdo dos dados da placa de som através do efeito 'Pitch Shift' (Desvio de Tom). Ajuste o parâmetro 'speed' (velocidade) para variar o efeito. + + + + +example_rc.arts + +Esta estrutura passa um gerador de 'ruído branco' através de um filtro RC para a placa de som. Ao ver no Osciloscópio de FFT do &artscontrol;, você poderá ver como isto varia numa forma de onda de ruído não filtrada. + + + + +example_sequence.arts + +Isto demonstra o módulo Sequence (sequência), tocando para tal uma sequência de notas. + + + + +example_shelve_cutoff.arts + +Esta estrutura passa um gerador de 'ruído branco' através de um filtro 'Shelve Cutoff' para a placa de som. Ao ver no Osciloscópio de FFT do &artscontrol;, você poderá ver como isto varia numa forma de onda de ruído não filtrada. + + + + +example_equalizer.arts + +Isto demonstra o módulo 'Std_Equalizer'. Ele aumenta de 6 dB as frequências altas e baixas. + + + + +example_tremolo.arts + +Isto demonstra o efeito Tremolo. Ele modula os canais esquerdo e direito usando um tremolo de 10 Hz. + + + + +example_xfade.arts + +Este exemplo mistura ondas sinusoidais de 440 e 880 Hz com um misturador cruzado. Ajuste o valor da percentagem do misturador de -1 até 1 para controlar a mistura dos dois sinais. + + + + +example_pscale.arts + +Isto ilustra o módulo do Pscale (não é certo se este será um exemplo compreensível). + + + + +example_play_wav.arts + +Isto ilustra o módulo 'Play Wave' (Tocar um WAVE). Você terá de indicar a localização completa de um ficheiro .wav como valor do parâmetro 'filename' (nome do ficheiro). + + + + +example_multi_add.arts + +Isto mostra o módulo Multi Add (Adição Múltipla), o qual aceita um número qualquer de entradas. Ele soma três módulos de dados que produzem entradas de 1, 2 e 3, mostrando depois o resultado 6. + + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/detail.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/detail.docbook new file mode 100644 index 00000000000..1f4d3e43f63 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/detail.docbook @@ -0,0 +1,1388 @@ + + + +O &arts; em Detalhe + + +Arquitectura + + + + + +A estrutura do &arts;. + + + + +Módulos & Portos + +A ideia do &arts; é que a síntese pode ser feita com módulos pequenos que só fazem uma coisa, voltando a combiná-los depois em estruturas complexas. Os pequenos módulos normalmente têm entradas, onde poderão obter alguns sinais ou parâmetros, e saídas, onde produzirão alguns sinais. + +Um módulo (o Synth_ADD), por exemplo, apanha simplesmente os dois sinais à entrada e adiciona-os em conjunto. O resultado fica disponível como um sinal de saída. Os locais onde os módulos oferecem os seus sinais de entrada e saída chamam-se portos. + + + + +Estruturas + +Uma estrutura é uma combinação de módulos ligados, alguns dos quais têm parâmetros codificados directamente nos seus portos de entrada, outros que poderão estar ligados e outros ainda que não estão ligados de todo. + +O que você pode fazer com o &arts-builder; é descrever as estruturas. Você descreve quais os módulos que quer que estejam ligados com outros módulos. Quando terminar, você poderá gravar a descrição dessa estrutura num ficheiro, ou dizer ao &arts; para criar essa estrutura que descreveu (Executar). + +Aí você irá provavelmente ouvir algum som, se fez tudo correctamente. + + + + + +Latência + + +O Que é a Latência? + +Suponha que tem uma aplicação chamada pling_rato (que fará um som de um pling se carregar num botão). A latência é o tempo que passa entre você pressionar o botão do rato com o seu dedo e você ouvir o som. A latência nesta configuração compõe-se por si só em várias latências, que poderão ter causas diferentes. + + + + +Latência em Aplicações Simples + +Nesta aplicação simples, a latência ocorre nestes sítios: + + + + +O tempo até o 'kernel' notificar o servidor do X11 que foi carregado um botão do rato. + + + +O tempo até o servidor do X11 notificar a sua aplicação que um botão do rato foi pressionado. + + + +O tempo até à aplicação 'pling_rato' decidir que este botão merece tocar um 'pling'. + + + +O tempo que leva à aplicação 'pling_rato' dizer ao servidor de som que deverá tocar um 'pling'. + + + +O tempo que leva para o 'pling' (que o servidor de som começa a misturar com a outra saída ao mesmo tempo) vá para os dados dos 'buffers', até que atinge a posição onde a placa de som reproduz o toque. + + + +O tempo que leva o som do 'pling' dos altifalantes a atingir o seu ouvido. + + + +Os primeiros três itens são latências externas ao &arts;. Elas são interessantes, mas saem do âmbito deste documento. Todavia, tenha em atenção que elas existem, por isso, mesmo que você tenha optimizado tudo o resto para valores muito baixos, você poderá não obter exactamente o resultado que calculou. + +Indicar ao servidor para tocar qualquer coisa envolve normalmente uma única chamada de &MCOP;. Existem medidas que confirmam isso, na mesma máquina e usando 'sockets' do domínio Unix, que dizem que, para dizer ao servidor para tocar algo, poderão ser feitas cerca de 9000 invocações por segundo na implementação actual. Espera-se que a maioria disto seja devido à sobrecarga no 'kernel', na mudança de uma aplicação para outra. Claro que este valor altera com o tipo exacto dos parâmetros. Se você transferir uma imagem inteira numa chamada, a chamada será mais lenta do que se transferir um valor inteiro. Aplica-se o mesmo para o valor devolvido. Contudo, para as cadeias de caracteres (como o nome do ficheiro WAV a tocar), isto não deverá ser nenhum problema. + +Isto significa que podemos aproximar este tempo a 1/9000 sec, o que fica abaixo de 0.15 ms. Concluir-se-á que isto não é relevante. + +A seguir vem o tempo entre o servidor começar a tocar e a placa de som a obter algo. O servidor precisa de armazenar os dados temporariamente em tampões ('buffers'), por isso quando as outras aplicações começarem a executar, como o seu servidor de X11 ou a aplicação pling_rato não se poderão ouvir quebras. A forma como isso é feito no &Linux; é recorrendo a um conjunto de fragmentos de determinado tamanho. O servidor voltará a preencher os fragmentos, e a placa de som irá reproduzi-los. + +Por isso, suponha que existem três fragmentos. O servidor preenche o primeiro, e a placa de som começa a tocá-lo. O servidor preenche o segundo e o terceiro, terminando assim a sua parte. As outras aplicações podem agora fazer algo. + +Dado que a placa de som acabou de tocar o primeiro fragmento, começa a tocar o segundo e o servidor volta a preencher o primeiro, repetindo este processo indefinidamente. + +A maior latência que você obtém com tudo isto é igual a (número de fragmentos)*(tamanho de cada fragmento)/(taxa amostragem * (tamanho de cada amostra)). Suponha que tem estéreo a 44kHz, com 7 fragmentos de 1024 bytes (o valor por omissão actual do &arts;): isso irá corresponder a 40 ms. + +Estes valores poderão ser ajustados de acordo com as suas necessidades. Todavia, a utilização do CPU aumenta com latências menores, dado que o servidor de som terá de preencher os tampões com maior frequência e em menores partes. É também quase impossível atingir valores melhores sem dar ao servidor de som a prioridade de tempo-real, porque caso contrário irá ter frequentes quebras. + +Contudo, é realista ter algo como 3 fragmentos de 256 bytes cada, o que iria fazer com que este valor fosse igual a 4,4 ms. Com um atraso de 4,4ms a utilização inactiva do CPU seria de aproximadamente 7,5% por parte do &arts;. Com um atraso de 40ms, seria de aproximadamente 3% (num PII-350, e este valor poderá depender da sua placa de som, versão do 'kernel', entre outros). + +Agora, finalmente, tem o tempo que leva o som do 'pling' a sair dos altifalantes e a chegar ao seu ouvido. Suponha que a sua distância até aos altifalantes é de 2 metros. O som viaja à velocidade de 330 metros por segundo. Por isso, esse tempo poder-se-á aproximar a 6 ms. + + + + +Latência em Aplicações de Transmissão + +As aplicações de transmissão ou difusão são aquelas que produzem elas próprias o som, e que origina uma sequência constanted de amostras, e que será agora adapto para reproduzir as coisas através do &arts;. Por exemplo: quando se pressiona uma tecla, a figura que está a tocar salta, aparecendo um som de 'boing'. + +Primeiro que tudo, você precisa de saber como é que o &arts; faz a transmissão. É bastante semelhante às E/S com a placa de som. O jogo envia alguns pacotes com amostras para o servidor de som. Imagine-se que são três pacotes. Assim que o servidor estiver pronto com o primeiro pacote, envia uma confirmação de volta para o jogo a dizer que este pacote está pronto. + +O jogo cria outro pacote de som e envia-o para o servidor. Entretanto o servidor começa a consumir o segundo pacote de som, e assim por diante. A latência aqui é semelhante à do caso simples: + + + +O tempo até que o 'kernel' notifique o servidor de X11 que uma tecla foi carregada. + + + +O tempo até que o servidor de X11 notifique o jogo de que uma tecla foi carregada. + + + +O tempo até que o jogo se decida que esta tecla merece tocar um 'boing'. + + + +O tempo até o pacote de som onde o jogo começou a colocar o som do 'boing' leva a chegar ao servidor de som. + + + +O tempo que leva ao 'boing' (que o servidor de som começa a misturar para de uma vez) passe para os dados nos tampões ('buffers'), até que atinja a posição em que a placa de som começa a tocar. + + + +O tempo que o 'boing' leva a sair dos altifalantes até atingir o seu ouvido. + + + + +As latências externas, tal como acima, estão fora do âmbito deste documento. + +Obviamente, a latência da transmissão depende do tempo que leva a todos os pacotes que são usados na transmissão a serem tocados uma vez. Deste modo, é igual a (número de pacotes)*(taxa de amostragem * (tamanho de cada amostra)) + +Como você vê, é a mesma fórmula que se aplica para os fragmentos. Contudo, para os jogos, não faz sentido fazer demoras tão pequenas. Pode-se dizer que uma configuração realista para os jogos seria de 2048 bytes por pacote, usando 3 pacotes. A latência resultante seria de 35 ms. + +Isto baseia-se no seguinte: assuma que o jogo desenha 25 imagens por segundo. É provavelmente seguro assumir que você não notará nenhuma diferença na saída de som para uma imagem. Por isso, 1/25 segundos para a transmissão é aceitável, o que por sua vez significa que 40 ms seria ok. + +A maioria das pessoas também não irão executar os seus jogos, com prioridade de tempo-real, onde o perigo de quebras no som não pode ser negligenciado. A transmissão com 3 pacotes de 256 bytes cada é possível (tentou-se isso) - mas provoca uma carga grande de CPU para a transmissão. + +para as latências do lado do servidor, você pode calculá-las exactamente como está dito em cima. + + + + +Algumas considerações de utilização do <acronym +>CPU</acronym +> + +Existem vários factores que influenciam a utilização do CPU num cenário complexo, com algumas aplicações de transmissão entre outras, alguns 'plugins' no servidor, &etc;. Só para indicar algumas: + + + +Utilização em bruto de CPU pelos cálculos que são necessários. + + + +A sobrecarga do escalonamento interno do &arts; - como é que o &arts; decide qual o módulo que deve calcular o quê. + + + +A sobrecarga da conversão de inteiros para números de vírgula flutuante. + + + +A sobrecarga do protocolo &MCOP;. + + + +'Kernel': mudança de contexto/processo. + + + +'Kernel': sobrecarga nas comunicações + + + +Para a carga em bruto do CPU usada nos cálculos, se você tocar duas sequências em simultâneo, você terá de efectuar somas. Se você aplicar um filtro, estão envolvidos alguns cálculos. Para dar um exemplo simplificado, a adição de duas sequências envolve talvez quatro ciclos de CPU por soma, o que num processador a 350MHz corresponde a 44100*2*4/350000000 = 0,1% utilização do CPU. + +Escalonamento interno do &arts;: o &arts; precisa de decidir qual o 'plugin' que irá calcular um dado conjunto de dados; isto leva tempo. Faça uma análise da performance se você estiver interessado nisso. Geralmente o que se pode dizer é: quanto menos de tempo-real fizer (&ie;. quanto maiores os blocos que poderão ser calculados numa dada altura), a menor sobrecarga de escalonamento você obterá. Acima do cálculo de blocos de 128 amostras de cada vez (usando deste modo tamanhos de fragmentos de 512 bytes), a sobrecarga no escalonamento não será grave. + +Conversão de inteiros para números de vírgula flutuante: o &arts; usa números de vírgula flutuante internamente como formato de dados. Este são simples de usr e nos processadores mais recentes não são mais lentos do que as operações com inteiros. Contudo, se existirem clientes que lidem com dados que não estejam em vírgula flutuante (como um jogo que deverá fazer a sua saída de som através do &arts;), estes precisam de ser convertidos. O mesmo aplica-se que você quiser reproduzir os sons na sua placa de som. A placa de som está à espera de inteiros, por isso você terá de converter. + +Aqui estão números para um Celeron, da quantidade aproximada de 'ticks' por amostra, com o egcs 2.91.66 com a opção -O2 (dados de Eugene Smith hamster@null.ru). Isto é altamente dependente do processador, como é óbvio: + +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 + + +Por isso significa 1% de utilização do CPU para a conversão e 5% para a interpolação para este processador de 350 MHz. + +A sobrecarga que o protocolo &MCOP; provoca; este protocolo origina, como regra de algibeira, 9000 invocações por segundo. Muitas destas não são culpa do protocolo &MCOP; em si, mas relaciona-se com as duas causas do 'kernel' indicadas em baixo. Contudo, isto fornece uma base para cálculo do quanto custa a transmissão. + +Cada pacote de dados que é transmitido poderá ser considerado uma invocação do &MCOP;. Claro que os pacotes grandes são mais lentos do que 9000 pacotes/s, mas isto é a ideia básica. + +Suponha que você usa tamanhos de pacotes de 1024 bytes. Deste modo, para transferir uma sequência estéreo de 44kHz, você precisa de transferir 44100*4/1024 = 172 pacotes por segundo. Suponha que po100% de utilização de CPU, 9000 pacotes, então iria obter (172*100)/9000 = 2% de utilização de CPU devido à transmissão de pacotes de 1024 bytes. + +Existem aproximações. Contudo, estas mostram que você poderia estar muito melhor (se o poder fazer para o bem da latência), se usasse por exemplo pacotes de 4096 bytes. Pode-se fazer aqui uma fórmula compacta, calculando o tamanho do pacote que provoca uma utilização de 100% do CPU como sendo igual a 44100*4/9000 = 19,6 amostras, obtendo assim a fórmula rápida: + +utilização de CPU na transmissão em percentagem = 1960/(tamanho do seu pacote) + +o que dará 0,5% de utilização do CPU ao transmitir com pacotes de 4096 bytes. + +Mudança de contextos/processos do 'kernel': isto faz parte da sobrecarga do protocolo &MCOP;. A mudança entre dois processos leva tempo. Existe um novo mapeamento de memória, as 'caches' são invalidadas, entre outras coisas (se existir alguém experiente no 'kernel' a ler isto - que diga quais são as causas exactas). Tudo isto para dizer: leva tempo. + +Não é certo quantas mudanças de contexto o I &Linux; consegue fazer por segundo, mas esse número não é infinito. Por isso, muita parte da sobrecarga do protocolo &MCOP; deve-se, supostamente, em grande medida à mudança de contextos. No início do &MCOP;, foram feitos testes para usar a mesma comunicação dentro de um processo e isso era muito mais rápido (quatro vezes mais rápido, aproximadamente). + +'Kernel': sobrecarga na comunicação: Isto faz parte da sobrecarga do protocolo &MCOP;. A transferência de dados entre processos é feita de momento, recorrendo a 'sockets'. Isto é conveniente, dado que os métodos normais do select() podem ser usados para determinar quando chegou uma mensagem. Também pode ser combinado com ou E/S de áudio, o servidor do X11 ou outras fontes, com relativa facilidade. + +Contudo, estas chamadas de leitura e escrita custam certamente ciclos processador. Para as invocações pequenas (como a transferência de um evento MIDI), isso não é provavelmente assim tão mau, mas para as chamadas pesadas (como a transferência de uma imagem de vídeo com vários megabytes), isto é claramente um problema. + +A utilização de memória partilhada no &MCOP;, sempre que apropriado, é provavelmente a melhor solução. Isto deverá ser feito de forma transparente para o programador da aplicação. + +Obtenha um analisador ('profiler') ou faça outros testes para descobrir exactamente como é que a transmissão de áudio tem impacto se usar ou não memória partilhada. Contudo, não é mau, dado que a transmissão de áudio (reproduzir MP3s, por exemplo) poderá ser feita com utilização total de 6% de carga do CPU pelo &artsd; e pelo artscat (e 5% pelo descodificador de MP3). Contudo, isto inclui todas as coisas, desde os cálculos necessários até à sobrecarga nos 'sockets', por isso poder-se-á dizer que, nesta configuração, você poderá talvez poupar 1% se usar memória partilhada. + + + + +Alguns Números em Bruto + +Estes são retirados a partir da versão actual em desenvolvimento. Tentou-se obter também casos reais, porque isso não é o que as aplicações do dia-a-dia deverão usar. + +Foi criada uma aplicação chamada 'som_sequencia' que transmite dados para o &arts;. Aqui está a correr com prioridade de tempo-real (sem problemas) e com um 'plugin' pequeno por parte do servidor (ajuste e recorte do volume): + +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 som_sequencia +5002 stefan 20 0 2208 2208 1684 S 0 6.8 1.7 0:07 som_sequencia +4997 stefan 20 0 2208 2208 1684 S 0 6.6 1.7 0:07 som_sequencia + + +Cada um deles está a transmitir com 3 fragmentos de 1024 bytes (18 ms). Existem três clientes do mesmo tipo a correr em simultâneo. É certo que isto parece demasiado, mas como foi dito: pegue num analisador ('profiler') e procure o que é que leva tempo e, se o desejar, tente melhorá-lo. + +Contudo, não se deve pensar que a utilização da transmissão desta forma é realista ou faz sentido. Para levar isto ainda mais ao extremo, tentou-se a menor latência possível. Resultado: você poderá fazer transmissões sem interrupções com uma aplicação-cliente, se tiver 2 fragmentos de 128 bytes entre o &arts; e a placa de som e entre a aplicação-cliente e o &arts;. Isto significa que você tem uma latência total máxima de 128*4/44100*4 = 3 ms, onde 1,5 ms são gerados devido à E/S da placa de som e os outros 1,5 devem-se à comunicação com o &arts;. Ambas as aplicações precisam de correr em tempo-real. + +Mas isto tem um custo enorme do CPU. Este exemplo custa-lhe cerca de 45% num P-II/350. Ele também começa a fazer 'clicks' se você iniciar o 'top', se mover as janelas no seu ecrã do X11 ou se fizer E/S de disco. Todas estas questões são respeitantes ao 'kernel'. O problema é que o escalonamento de duas ou mais aplicações em tempo-real custam-lhe uma quantidade enorme de esforço também, e ainda mais se elas comunicarem, notificarem-se uma à outra, &etc;. + +Finalmente, um exemplo mais real. Isto é o &arts; com o &artsd; e um 'artscat' (um cliente de transmissão) que estão a correr 16 fragmentos de 4096 bytes: + +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 + + + + + + + + +Barramentos + +Os barramentos são ligações criadas dinamicamente que transferem o áudio. Basicamente, existem alguns canais de envio e de recepção e de envio. Todos os sinais dos canais de envio são adicionados e enviados para os canais de recepção. + +Os barramentos, tal como são implementados actualmente, operam em estéreo, por isso você só poderá transferir dados em estéreo nos barramentos. Se você quiser dados mono, bem, transfira apenas por um canal e coloque o outro a zeros ou com outro valor qualquer. Tudo o que precisa de fazer é criar um ou mais objectos Synth_BUS_UPLINK e dar-lhes o nome de um barramento, com o qual eles deverão falar (⪚ áudio ou bateria). Basta largar os dados aí. + +Aí, você terá de criar um ou mais objectos Synth_BUS_DOWNLINK, indicando-lhe o nome do barramento (áudio ou bateria ... se corresponde, os dados serão transferidos para aí), e os dados misturados irão sair de novo. + +Os canais de envio e de recepção poderão residir em estruturas diferentes, e você até poderá ter vários &arts-builder;s diferentes a correr e iniciar um canal de envio num e receber os dados noutro, através do canal de recepção respectivo. + +O que é interessante acerca dos barramentos é que eles são completamente dinâmicos. Os clientes poder-se-ão ligar instantaneamente. Não deverá haver nenhum 'click' ou ruído à medida que isto acontece. + +Claro que você não deverá desligar um cliente que toca um sinal, dado que poderá não estar a um nível nulo quando for desligado do barramento, ao que se ouvirá então um 'click'. + + + + +Mediador + +O &arts;/&MCOP; baseia-se em grande medida na divisão das coisas em pequenos componentes. Isto torna as coisas muito flexíveis, à medida que vai extendendo o sistema facilmente com a adição de componentes novos que implementam efeitos novos, formatos de ficheiros, osciladores, elementos gráficos.... Dado que quase tudo é um componente, quase tudo poderá ser extendido facilmente, sem alterar o código existente. Os componentes novos poderão ser simplesmente carregados dinamicamente para melhorar as aplicações já existentes. + +Contudo, para isto funcionar, são necessárias duas coisas: + + + + +Os componentes têm de se publicitar a eles próprios - eles precisam de descrever quais as coisas que eles oferecem, para que as aplicações sejam capazes de as usar. + + + +As aplicações precisam de procurar activamente os componentes que elas poderão usar, em vez de usar sempre a mesma coisa para uma dada tarefa. + + + + +A combinação disto - os componentes que dizem aqui estou eu, sou bom, usem-me, e as aplicações (ou, se preferir, outros componentes) que vão e procuram qual o componente que eles poderão usar para ter uma coisa feita - é o que é chamado de 'mediação' ou 'negociação'. + +No &arts;, os componentes descrevem-se a si próprios, indicando valores que suportam para as propriedades.. Uma propriedade típica para um componente de leitura de ficheiros poderá ser a extensão dos ficheiros que pode processar. Os valores típicos poderão ser o wav, o aiff ou o mp3. + +De facto, todos os componentes poderão optar por oferecer vários valores diferentes para uma dada propriedade. Por isso, um único componente poder-se-á oferecer para ler tanto os ficheiros wav como os aiff, indicando que suporta estes valores para a propriedade Extension (Extensão). + +Para o fazer, um componente terá de colocar um ficheiro .mcopclass num local apropriado, contendo as propriedades que suporta; no caso do exemplo actual, isto poderá assemelhar-se ao seguinte (e estará instalado como dir_componente/Arts/WavPlayObject.mcopclass): + +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 + + +É importante que o nome do ficheiro .mcopclass também diga como é que se chama a interface do componente. O mediador não olha para o conteúdo de todo, se o ficheiro (tal como está aqui) se chamar Arts/WavPlayObject.mcopclass, a interface do componente é chamada de Arts::WavPlayObject (os módulos mapeiam-se nas pastas). + +Para ver os componentes, existem duas interfaces (que estão definidas em core.idl, por isso você irá tê-las em todas as aplicações), chamadas de Arts::TraderQuery e Arts::TraderOffer. Você poderá fazer uma ida às compras nos componentes deste tipo: + + + +Crie um objecto de pesquisa: +Arts::TraderQuery pesquisa; + + + + +Indique o que pretende. Como viu em cima, os componentes descrevem-se a si próprios recorrendo a propriedades, para os quais eles oferecem determinados valores. Por isso, poderá indicar o que quiser através da selecção de componentes que suportem um dado valor para uma dada propriedade. Isto é feito se usar o método 'supports' de uma TraderQuery: + +pesquisa.supports("Interface","Arts::PlayObject"); + pesquisa.supports("Extension","wav"); + + + + +Finalmente, efectue a pesquisa usando o método 'query'. Aí, você irá obter (ou assim se espera) algumas ofertas: + +vector<Arts::TraderOffer> *ofertas = pesquisa.query(); + + + + +Agora você poderá examinar o que encontrou. O que é importante é o método 'interfaceName' do TraderOffer, o qual lhe dirá o nome do componente que correspondeu à pesquisa. Você poderá também encontrar mais propriedades com o método 'getProperty'. O código seguinte irá simplesmente iterar por todos os componentes, imprimir o nome das suas interfaces (que poderão ser usados na criação), e limpar os resultados da pesquisa de novo: +vector<Arts::TraderOffer>::iterator i; + for(i = ofertas->begin(); i != ofertas->end(); i++) + cout << i->interfaceName() << endl; + delete ofertas; + + + + +Para este tipo de serviço de mediação ser útil, é importante concordar de alguma forma nos tipos de propriedades que os componentes deverão definir normalmente. É essencial que mais ou menos todos os componentes de uma determinada área usem o mesmo conjunto de propriedades para se descreverem a si próprios (e o mesmo conjunto de valores, sempre que se aplicar), de modo a que as aplicações (ou as outras componentes) sejam capazes de os encontrar. + +Author (tipo 'texto', opcional): Isto poderá ser usado para mostrar em última instância ao mundo que você fez algo. Aqui você poderá escrever tudo o que quiser, se bem que um endereço de e-mail é obviamente útil. + +Buildable (tipo booleano, recomendado): Isto indica se o componente pode sre usado com ferramentas de RAD (como o &arts-builder;) que usam os componentes, atribuindo-lhes propriedades e ligando os seus portos. Recomenda-se ter este valor a 'true' (verdadeiro) para quase todos os componentes de processamento de sinal (como os filtros, efeitos, osciladores, ...) e para todas as outras coisas que podem usadas numa abordagem RAD, mas não para coisas internas como, por exemplo, o Arts::InterfaceRepo. + +Extension (tipo texto, onde for relevante): Tudo o que lide com ficheiros deverá optar por usar isto. Você deverá colocar aqui a versão em minúsculas da extensão do ficheiro sem o ., como por exemplo wav. + +Interface (tipo texto, obrigatório): Isto deverá incluir a lista completa de interfaces (úteis) que os seus componentes suportam, incluindo provavelmente o Arts::Object e, se se aplicar, o Arts::SynthModule. + +Language (tipo texto, recomendado): Se você quiser que o seu componente seja carregado dinamicamente, você precisa de indicar aqui a linguagem. De momento, o único valor permitido é o C++, o que significa que o componente foi criado com a API normal de C++. Se o fizer, você também terá de definir a propriedade Library em baixo. + +Library (tipo texto, usado quando relevante): Os componentes feitos em C++ podem ser carregados dinamicamente. Para o fazer, você terá de os compilar num módulo de biblioteca carregada dinamicamente (.la). Aqui você poderá indicar o nome do ficheiro .la. Lembre-se de usar o REGISTER_IMPLEMENTATION (como sempre). + +MimeType (tipo texto, usado quando for relevante): Tudo o que lide com ficheiros deverá optar por usar isto. Você deverá colocar aqui a versão em minúsculas do tipo MIME normal, como por exemplo audio/x-wav. + +&URL; (tipo texto, opcional): Se quiser que as pessoas saibam onde poderão obter uma nova versão do componente (ou uma página pessoal, ou algo do género), você podê-lo-á fazer aqui. Isto deverá ser um &URL; normal de &HTTP; ou de &FTP;. + + + + + + +Espaços de nomes no &arts; + + +Introdução + +Cada declaração de espaço de nomes corresponde à declaração de um módulo na &IDL; do &MCOP;. + +// idl de mcop + +module M { + interface A + { + } +}; + +interface B; + + +Neste caso, o código de C++ gerado para o excerto de &IDL; deverá ser algo semelhante a isto: + +// código de C++ + +namespace M { + /* declaração de A_base/A_skel/A_stub e itens semelhantes */ + class A { // Classe de interface de referência + /* [...] */ + }; +} + +/* declaração de B_base/B_skel/B_stub e itens semelhantes */ +class B { + /* [...] */ +}; + + +Por isso, quando se referir às classes do seu código em C++, você terá de escrever M::A, mas só B. Todavia, você poderá indicar using M algures - como em qualquer 'namespace' do C++. + + + + +Como o &arts; usa os espaços de nomes + +Existe um espaço de nomes global chamado Arts, o qual todos os programas e bibliotecas usam para colocar lá as suas declarações. Isto significa que, ao criar código em C++ que dependa do &arts;, você terá normalmente de anteceder cada classe que usar com o Arts::, tal como se segue: + +int main(int argc, char **argv) +{ + Arts::Dispatcher mediador; +" Arts::SimpleSoundServer servidor(Arts::Reference("global:Arts_SimpleSoundServer")); + + servidor.play("/var/xpto/um_ficheiro.wav"); + + +A outra alternativa é usar um 'using', tal como se segue: + +using namespace Arts; + +int main(int argc, char **argv) +{ + Dispatcher mediador; + SimpleSoundServer servidor(Reference("global:Arts_SimpleSoundServer")); + + servidor.play("/var/xpto/um_ficheiro.wav"); + [...] + + +Nos ficheiros &IDL;, você não tem de facto escolha alguma. Se estiver a fazer código que pertença ao &arts; em si, você terá de o pôr no módulo do &arts;. + +// Ficheiro IDL para código do aRts: +#include <artsflow.idl> +module Arts { // colocar no espaço de nomes Arts + interface Synth_AJUSTE : SynthModule + { + in audio stream entrada; + out audio stream saida; + attribute float factorAjuste; + }; +}; + + +Se você fizer código que não pertença ao &arts; em si, você não o deverá colocar no espaço de nomes Arts. Contudo, você poderá criar um espaço de nomes próprio se quiser. Em qualquer dos casos, você terá de anteceder as classes que usar do &arts;. + +// Ficheiro IDL para código que não pertence ao aRts: +#include <artsflow.idl> + +// pode criar sem declaração do módulo, onde as classes geradas não irão +// usar nenhum 'namespace' (espaço de nomes): +interface Synth_AJUSTE2 : Arts::SynthModule +{ + in audio stream entrada; + out audio stream saida; + attribute float factorAjuste; +}; + +// contudo, você também poderá escolher o seu espaço de nomes, se preferir, por +// isso se criar uma aplicação "Radio", você poderá fazê-lo da seguinte forma: +module Radio { + struct Estacao { + string nome; + float frequencia; + }; + + interface Sintonizador : Arts::SynthModule { + attribute Estacao estacao; // não é necessário anteceder o Estacao, por ser do mesmo módulo + out audio stream esquerda, direita; + }; +}; + + + + + +Detalhes Internos: Como Funciona a Implementação + +Normalmente, nas interfaces, conversões ('casts'), assinaturas dos métodos e noutras situações semelhantes, o &MCOP; precisa de se referir aos nomes dos tipos ou das interfaces. Estes são representados como texto nas estruturas de dados comuns do &MCOP;, enquanto que o espaço de nomes é sempre representado por completo no estilo do C++. Isto significa que os textos iriam conter M::A e B, seguindo o exemplo acima. + +Repare que isto se aplica mesmo se, dentro do texto do &IDL;, os qualificadores de espaços de nomes não foram indicados, dado que o contexto tornou claro qual a o espaço de nomes em que a interface A pretendia ser usada. + + + + + +Tarefas no &arts; + + +Básicos + +A utilização de tarefas ('threads') em todas as plataformas não é possível. Foi por isso que o &arts; originalmente foi feito sem qualquer suporte multitarefa. Para quase todos os problemas, para cada solução multitarefa para o problema, existe uma solução monotarefa que faz o mesmo. + +Por exemplo, em vez de colocar a saída de áudio numa tarefa em separado, tornando-a bloqueante, o &arts; usa a saída de áudio não-bloqueante, e tenta descobrir quando deve escrever os próximos blocos de dados com o select(). + +Contudo, o &arts; (em versões muito recentes) oferece pelo menos o suporte para as pessoas que queiram implementar os seus objectos com tarefas separadas. Por exemplo, se você já tiver código para um leitor de mp3 e o código do descodificador de mp3 está à espera de correr numa tarefa separada, é normalmente o acto mais fácil manter este desenho. + +A implementação do &arts;/&MCOP; é desenhada tendo como ideia de base a partilha do estado entre os objectos separados, implementada de formas óbvias ou menos óbvias. Uma pequena lista do estado partilhado inclui: + + +O objecto Dispatcher (mediador) que faz a comunicação do &MCOP;. + + + +A contagem de referências (interfaces inteligentes). + + + +O IOManager (gestor de E/S) que vigia os temporizadores e descritores de ficheiros. + + + +O ObjectManager (gestor de objectos), que cria os objectos e carrega automaticamente os 'plugins'. + + + +O FlowSystem (sistema de fluxo) que invoca o 'calculateBlock' nas situações apropriadas. + + + +Todos os objectos acima não estão à espera de ser usados concorrentemente (&ie; chamados em tarefas separadas ao mesmo tempo). Normalmente, existem duas formas de resolver isto: + + + +Obrigar ao invocador de todas as funções nestes objectos a adquirir um bloqueio antes de as usar. + + + +Tornar estes objectos realmente seguros em multitarefa e/ou criar instâncias por cada tarefa das mesmas. + + + +O &arts; segue a primeira aproximação: você terá de bloquear os objectos sempre que precisar de comunicar com qualquer um deles. A segunda aproximação é mais difícil de conseguir. Um truque que tenta obter isto está disponível em http://space.twc.de/~stefan/kde/download/arts-mt.tar.gz, mas nesta altura do campeonato, funcionará melhor uma aproximação minimalista, e causará menos problemas com as aplicações existentes. + + + +Quando/como efectuar o bloqueio? + +Você poderá efectuar/libertar o bloqueio com as duas funções: + + + + +Arts::Dispatcher::lock() + + + + +Arts::Dispatcher::unlock() + + + + +Geralmente, você não terá de efectuar o bloqueio (e não deverá ter de tentar fazê-lo), se já foi efectuado anteriormente. Segue-se uma lista com as condições em que este é o caso: + + + +Você recebe uma chamada de resposta do IOManager (um temporizador ou um descritor). + + + +Você é invocado devido a algum pedido do &MCOP;. + + + +Você é chamado a partir do NotificationManager (gestor de notificações). + + + +Você é invocado a partir do FlowSystem (pelo 'calculateBlock') + + + +Existem também algumas excepções de funções que você só poderá invocar na tarefa principal e que, por essa razão, nunca irá necessitar de bloquear para as chamar: + + + +O construtor/destrutor do Dispatcher/IOManager. + + + +Dispatcher::run() / IOManager::run() + + + +IOManager::processOneEvent() + + + +Mas é tudo. Para tudo o resto que esteja relacionado de qualquer forma com o &arts;, você irá necessitar de obter o bloqueio e libertá-lo quando terminar - sempre. Aqui está um exemplo simples: + +class TarefaTempoSuspensao : Arts::Thread { +public: + void run() { + /* + * você precisa deste bloqueio porque: + * - a criação de uma referência necessita de um bloqueio (porque o + * 'global:' vai para o gestor de objectos, o qual poderá necessitar + * por seu turno do objecto GlobalComm para procurar onde se ligar) + * - a atribuição de uma interface inteligente necessita de um + * bloqueio + * - a construção de um objecto a partir de uma referência necessita * de um bloqueio (porque poderá necessitar de se ligar a um + * servidor) + */ + Arts::Dispatcher::lock(); + Arts::SoundServer servidor = Arts::Reference("global:Arts_SoundServer"); + Arts::Dispatcher::unlock(); + + for(;;) { /* + * você precisa de bloquear aqui, por que + * - libertar a referência a uma interface inteligente necessita + * de um bloqueio (porque poderá fazer uma criação tardia) + * - fazer uma invocação do MCOP necessita de efectuar um bloqueio + */ + Arts::Dispatcher::lock(); + long segundos = servidor.secondsUntilSuspend(); + Arts::Dispatcher::unlock(); + + printf("segundos até à suspensão = %d",segundos); + sleep(1); + } + } +} + + + + + + +Classes relacionadas com tarefas + +As seguintes classes relacionadas com tarefas estão disponíveis de momento: + + + +O Arts::Thread - que encapsula uma tarefa. + + + +O Arts::Mutex - que encapsula um 'mutex' - uma exclusão mútua. + + + +O Arts::ThreadCondition - que oferece o suporte para acordar as tarefas que estão à espera que uma dada condição se torne verdadeira. + + + +O Arts::SystemThreads - que encapsula a camada do suporte multitarefa do sistema operativo (e que oferece algumas funções úteis para os programadores das aplicações). + + + +Veja os 'links' para obter mais documentação. + + + + + +Referências e Tratamento de Erros + +As referências no &MCOP; são um dos conceitos mais centrais na programação com o &MCOP;. Esta secção irá tentar descrever como é que as referências são usadas ao certo, e irá também tentar especialmente cobrir os casos de falha ). + + +Propriedades básicas das referências + + + +Uma referência de &MCOP; não é um objecto, mas sim a referência a um objecto: Ainda que a seguinte declaração + Arts::Synth_PLAY p; + se pareça com a definição de um objecto, apenas declara a referência a um objecto. Como programador de C++, você poderá pensar nisto como um Synth_PLAY *, um tipo de ponteiro para um objecto Synth_PLAY. Isto significa especialmente que o 'p' poderá ser a mesma coisas que um ponteiro nulo (NULL). + + + +Você poderá criar uma referência a NULL (valor nulo), atribuindo este valor explicitamente +Arts::Synth_PLAY p = Arts::Synth_PLAY::null(); + + + + +Invocar objectos numa referência NULL irá conduzir a um estoiro +Arts::Synth_PLAY p = Arts::Synth_PLAY::null(); + string s = p.toString(); + +irá levar a um estoiro. Se comparar isto com um ponteiro, é exactamente o mesmo que + QWindow* janela = 0; + janela->show(); +, o qual todos os programadores de C++ sabem que deverão evitar. + + + +Os objectos não-inicializados tentar-se-ão criar 'a posteriori' quando forem usados pela primeira vez + +Arts::Synth_PLAY p; + string s = p.toString(); + +é algo diferente de fazer uma referência a um ponteiro NULL. Você não indicou ao objecto de todo o que ele é, e agora irá tentar usá-lo. A questão aqui é que você deseja ter uma instância local de um objecto Arts::Synth_PLAY. Claro que você poderá querer ter algo diferente (como criar o objecto noutro local qualquer, ou usar um objecto remoto existente). Contudo, é um atalho conveniente para criar objectos. A criação tardia não irá funcionar logo que tenha atribuído outra coisa qualquer (como por exemplo uma referência nula). + +Os termos equivalentes em C++ seriam + QWidget* janela; + janela->show(); + o que obviamente, em C++, iria dar um estoiro garantido. Por isso, isto é diferente aqui. Esta criação tardia é enganadora, porque não quer dizer que exista necessariamente uma implementação para a sua interface. + +Por exemplo, considere uma coisa abstracta como um Arts::PlayObject. Existem decerto PlayObjects concretos como os que existem para tocar MP3s ou WAVs, mas o + Arts::PlayObject objecto; + objecto.play(); + irá falhar de certeza. O problema é que, ainda que a criação tardia funcione e tente criar um PlayObject, irá falhar, dado que existem coisas do tipo Arts::WavPlayObject e outros do género. Daí, use a criação tardia apenas se tiver a certeza que existe uma implementação. + + + +As referência podem apontar para o mesmo objecto + +Arts::SimpleSoundServer s = Arts::Reference("global:Arts_SimpleSoundServer"); + Arts::SimpleSoundServer s2 = s; + + +cria duas referências para o mesmo objecto. Isto não copia nenhum valor e não cria dois objectos. + + + +Todos objectos fazem contagem das referências. Por isso, logo que um objecto já não seja mais referenciado por nenhum outro objecto, é removido. Não existe nenhuma forma explícita de remover um objecto, contudo poderá usar algo do género + Arts::Synth_PLAY p; + p.start(); + [...] + p = Arts::Synth_PLAY::null(); + para fazer com que o objecto Synth_PLAY se vá embora no fim. Especialmente não deverá ser necessário usar o 'new' e o 'delete' em conjunto com as referências. + + + + + + +O caso de falha + +Dado que as referências poderão apontar para objectos remotos, os servidores que contenham esses objectos poderão estoirar. O que acontece então? + + + + +Um estoiro não muda se uma referência é nula. Isto significa que, se o xpto.isNull() foi true antes de um estoiro do servidor, então também será true depois do estoiro (o que parece claro). Significa também que, se o xpto.isNull() foi false antes de um estoiro do servidor (o 'xpto' fazia referência a um objecto), então também será false depois do estoiro do servidor. + + + +A invocação dos métodos numa referência válida mantém-se segura. Suponha que o servidor que contém o objecto 'calc' estoirou. Se continuar a invocar coisas do tipo + int k = calc.subtrair(i,j) + estas serão seguras. Obviamente, o 'subtrair' terá de devolver algo aqui, o que não consegue porque o objecto remoto já não existe mais. Nesse caso, o (k == 0) será verdadeiro. Geralmente, as operações tentam devolver algo neutro como resultado, como por exemplo 0,0, uma referência nula para os objectos ou textos em branco, sempre que o objecto não existir mais. + + + +Se invocar o error() verá se algo correu bem ou mal. + +No caso de cima, o + int k = calc.subtrair(i,j) + if(k.error()) { + printf("O k não é igual a i-j!\n"); + } + iria imprimir O k não é igual a i-j sempre que a invocação remota não funcionasse. Caso contrário, o k é de facto o resultado da operação 'subtrair' efectuada pelo objecto remoto (sem estoiro do servidor). Contudo, para os métodos que fazem coisas como remover ficheiros, você não poderá saber de certeza se isso de facto aconteceu. Claro que aconteceu se o .error() devolveu false. Contudo, se o .error() devolveu true, existem duas possibilidades: + + + +O ficheiro foi removido, e o servidor estoirou logo depois de o remover, mas antes de transferir o resultado. + + + +O servidor estoirou antes de ser capaz de remover o ficheiro. + + + + + +O uso de invocações aninhadas é perigoso em programas resistentes a estoiros + +Se usar algo do tipo + janela.titlebar().setTitle("xpto"); + não é uma boa ideia. Suponha que você sabia que essa janela era uma referência de Window válida. Agora suponha que sabe que o janela.titlebar() iria devolver uma referência a Titlebar porque o objecto Window foi criado correctamente. Todavia, ainda a frase acima não é segura. + +O que poderia acontecer é que o servidor que continha o objecto Window tinha estoirado. Aí, independentemente de quão válida fosse a implementação de Window, você iria obter uma referência nula como resultado da operação 'janela.titlebar()'. E aí, obviamente, a invocação de 'setTitle' nessa referência nula iria provocar um estoiro à mesma. + +Por isso, uma variante segura disto seria + Titlebar titulo = janela.titlebar(); + if(!janela.error()) + titulo.setTitle("xpto"); +, adicionando o tratamento de erros apropriado, se o desejar. Se você não confiar na implementação de Window, você poderá também usar + Titlebar titulo = janela.titlebar(); + if(!titulo.isNull()) + titulo.setTitle("xpto"); + em que ambas são seguras. + + + +Existem outras condições de falha, como a quebra de rede (suponha que você retira o cabo entre o seu servidor e o cliente enquanto a sua aplicação corre). Contudo, o efeito é o mesmo que um estoiro do servidor. + +De um modo geral, é claro uma questão de política a forma como você tenta eliminar os erros de comunicação na sua aplicação. Você poderá seguir o método de se o servidor estoirar, é necessário depurar o servidor até que nunca mais estoire de novo, o que significaria que você não se precisa de se incomodar com todos esses problemas. + + + + +Detalhes Internos: Contagem de Referências Distribuída + +Um objecto, para existir, precisa de pertencer a alguém. Se não pertencer, deixará de existir (mais ou menos) imediatamente. Internamente, a pertença é indicada ao chamar o _copy(), o qual incrementa uma contagem de referências e é devolvida ao invocar o _release(). Logo que a contagem de referências chegue a zero, será feito um 'delete'. + +Como variação do tema, a utilização remota é indicada pelo _useRemote() e desfeita pelo _releaseRemote(). Estas funções mantêm uma lista dos servidores que invocaram o objecto (e que, por esse motivo, o possuem). Isto é usado no caso deste servidor se desligar (&ie; estoiro, falha de rede), para remover as referência que ainda existem nos objectos. Isto é feito com o _disconnectRemote(). + +Agora existe um problema. Considere um valor devolvido. Normalmente, o objecto do valor devolvido não pertencerá mais à função que foi chamada. Também não pertencerá à função que chamou, até que a mensagem que mantém o objecto seja recebida. Deste modo, existe um tempo para os objectos sem dono. + +Agora, ao enviar um objecto, poder-se-á assumir que, assim que seja recebido, passará a ter um dono de novo, a menos que, mais uma vez, o receptor morra. Contudo, isto significa que é preciso ter um cuidado especial com os objectos, pelo menos ao enviá-los e provavelmente ao recebê-los, de modo a que não morra de uma vez. + +A forma como o &MCOP; faz isto é marcando os objectos que estão em vias de ser copiados para a rede. Antes de se dar início a uma cópia, o _copyRemote é invocado. Isto evita que o objecto seja libertado durante algum tempo (5 segundos). Logo que o receptor invoque o _useRemote(), a marca é removida de novo. Deste modo, todos os objectos que são enviado para a rede são marcados antes da transferência. + +Se o receptor obtiver um objecto que está no seu servidor, é óbvio que ele não irá invocar o _useRemote(). Para esse caso especial, o _cancelCopyRemote() existe para remover a marca manualmente. Para além disso, existe também a remoção de marcas temporizada, se tiver sido feita a marcação mas o destinatário não recebeu de facto o objecto (devido a um estoiro ou falha de rede). Isto é feito com a classe ReferenceClean. + + + + + + +Elementos &GUI; + +Os elementos &GUI; estão neste momento num estado experimental. Contudo, esta secção irá descrever o que é suposto acontecer aqui por isso, se você for um programador, você será capaz de perceber como é que o &arts; irá lidar com as &GUI;s no futuro. Existe já algum código, também. + +Os elementos &GUI; deverão ser usados para permitir às estruturas de síntese interagirem com o utilizador. No caso mais simples, o utilizador deverá ser capaz de modificar alguns parâmetros de uma estrutura directamente (como um factor de ganho que é usado antes do módulo final de reprodução). + +Nas opções mais complexas, pode-se imaginar que o utilizador deseja modificar os parâmetros de grupos de estruturas e/ou ainda não tem as estruturas a correr, como a modificação do envelope ADSR do instrumento &MIDI; activo no momento. Outra coisa seria mudar o nome do ficheiro de um instrumento baseado em amostras. + +Por outro lado, o utilizador poderá querer monitorizar o que o sintetizador está a fazer. Poderão existir osciloscópios, analisadores de espectro, medidores de volume e outras experiências que mostram a curva de transferência na frequência de um dado módulo de filtragem. + +Finalmente, os elementos &GUI; deverão ser capazes de controlar a estrutura completa de o que é que está a correr dentro do &arts; e como. O utilizador deverá ser capaz de associar instrumentos a canais &MIDI;, iniciar novos processadores de efeitos, configurar a sua mesa de mistura principal (a qual é ela própria baseada em estruturas do &arts;) para ter mais um canal e usar outra estratégia para os seus equalizadores. + +Você pode ver - os elementos GUI deverão trazer todas as possibilidades do estúdio virtual que o &arts; deverá simular para o utilizador. Claro, eles deverão interagir de forma ordeira com as entradas &MIDI; (assim como as barras se deverão mexer se elas tiverem entradas &MIDI; que mudem também esse parâmetro), e provavelmente até elas próprias gerarem eventos, para permitir a interacção com o utilizador ser registada com o sequenciador. + +Tecnicamente, a ideia é ter uma classe de base de &IDL; para todos os elementos (a Arts::Widget), e derivar um conjunto de elementos comuns desta (como o Arts::Poti, o Arts::Panel, o Arts::Window, ...). + +Aí, poder-se-á implementar estes elementos com uma biblioteca, como por exemplo o &Qt; ou o Gtk. Finalmente, os efeitos deverão criar as suas &GUI;s a partir dos elementos existentes. Por exemplo, um ' poderia criar a sua interface a partir de cinco objectos Arts::Poti e de uma Arts::Window. Por isso, SE existir uma implementação do &Qt; para esses elementos de base, o efeito deverá ser capaz de se apresentar, usando o &Qt;. Se existir uma implementação para Gtk, então deverá também funcionar para o Gtk (e assemelhar-se/funcionar mais ou menos da mesma forma). + +Finalmente, dado que tem sido utilizada aqui a &IDL;, o &arts-builder; (ou outras ferramentas), serão capazes de ligar as interfaces visualmente, ou gerar automaticamente as interfaces com base nos parâmetros definidos, baseando-se apenas nas interfaces. Deverá ser relativamente simples criar uma classe para criar uma &GUI; a partir da descrição, que obtém uma descrição da &GUI; (contendo os vários parâmetros e elementos) e criar um objecto gráfico vivo a partir dele. + +Baseando-se na &IDL; e no modelo de componentes do &arts;/&MCOP;, deverá ser simples extender os objectos possíveis que podem ser usados na &GUI; de forma tão simples como para adicionar um 'plugin' que implementa um novo filtro para o &arts;. + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/digitalaudio.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/digitalaudio.docbook new file mode 100644 index 00000000000..d0fe3eb41c6 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/digitalaudio.docbook @@ -0,0 +1,16 @@ + + + +Introdução ao Áudio Digital + +amostragem digital, filtros, efeitos, &etc; + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/faq.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/faq.docbook new file mode 100644 index 00000000000..733bb78ef76 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/faq.docbook @@ -0,0 +1,1312 @@ + + +Perguntas e respostas + +Esta secção responde a algumas questões perguntadas frequentemente sobre o &arts;. + + +Perguntas Gerais + + + +Será que o &kde; suporta a minha placa de som para a saída de áudio? + + + +O &kde; usa o &arts; para tocar som, e o &arts; usa os controladores do 'kernel' do &Linux;, sejam o OSS ou o ALSA (usando a emulação do OSS). Se a sua placa de som é suportada ou pelo ALSA ou pelo OSS e se estiver configurada convenientemente (&ie; qualquer outra aplicação do &Linux; consegue dar som), irá funcionar aqui também. Existem contudo alguns problemas com algum 'hardware' específico; por favor leia a secção sobre os problemas específicos do 'hardware' se estiver a ter problemas com o 'artsd' na sua máquina. +Entretanto, também foi adicionado o suporte para outras plataformas. Aqui está uma lista completa de como a versão mais recente do &arts; poderá tocar som. Se você tiver uma plataforma que não está suportada, por favor pense e alterar o &arts; e migrá-lo para a sua plataforma. + + + + + +método de E/S de áudio do &arts; +Comentário + + + + + +paud +Suporte para o Dispositivo de Áudio Pessoal do AIX + + + +alsa +Controladores ALSA-0.5 e ALSA-0.9 do Linux + + + +libaudioio +O suporte para a biblioteca genérica LibAudioIO que funciona no Solaris + + + +nas +O servidor de som NAS, útil nos terminais X que têm suporte de NAS + + + +null +Dispositivo de áudio nulo; elimina o som silenciosamente + + + +oss +O suporte do OSS (Open Sound System) (funciona no Linux, em vários BSDs e outras plataformas com controladores OSS instalados). + + + +toss +Suporte multitarefa do OSS, o qual funciona melhor em certos casos onde o suporte normal do OSS não funciona bem + + + +sgi +O suporte do SGI Direct Media para o IRIX + + + +sun +O suporte para o Solaris + + + + + + + + + + +Não consigo tocar ficheiros wav com o &artsd;! + + + +Verifique se o &artsd; está compilado com a libaudiofile (faça ldd artsd). Se não estiver, obtenha o 'kdesupport', recompile tudo e irá funcionar. + + + + + +Consigo ouvir som quando me ligo como root, mas os outros utilizadores não têm som! + + + +As permissões do ficheiro /dev/dsp afectam os utilizadores que terão som. Para permitir que toda a gente o utilize, faça isto: + + + +Ligue-se como root. + + + +Abra uma janela do &konqueror;. + + + +Vá para a pasta /dev. + + + +Carregue no ficheiro dsp com o botão direito do rato, escolhendo de seguida as Propriedades. + + + +Carregue na página Permissões. + + + +Assinale as opções Ler e Escrever em todas as secções. + + + +Carregue em OK. + + + +Você poderá obter o mesmo efeito numa janela de terminal com o comando chmod /dev/dsp. + +Para restringir o acesso ao som para apenas alguns utilizadores, você poderá usar as permissões do grupo. Em algumas distribuições de &Linux;, como por exemplo a Debian/Potato, o /dev/dsp já pertence a um grupo chamado audio, por isso, tudo o que terá de fazer é adicionar os utilizadores a esse grupo. + + + + + +Isto ajuda para o &artsd;, mas e então o &kmix;, o &kmid;, o &kscd;,&etc;? + + + +Existem vários outros dispositivos que oferecem funcionalidades acedidas pelas aplicações multimédia. Você poderá tratá-las da mesma forma, quer estando acessíveis para todos, quer usando grupos para controlar o acesso. Aqui está uma lista, a qual poderá estar à mesma incompleta (também se existirem vários dispositivos num formato do tipo midi0, midi1, ..., então só a versão 0 está aqui indicada): + + + + +/dev/admmidi0 + + + + +/dev/adsp0 + + + + +/dev/amidi0 + + + + +/dev/amixer0 + + + + +/dev/audio + + + + +/dev/audio0 + + + + +/dev/cdrom + + + + +/dev/dmfm0 + + + + +/dev/dmmidi0 + + + + +/dev/dsp + + + + +/dev/dsp0 + + + + +/dev/midi0 + + + + +/dev/midi0 + + + + +/dev/midi00 + + + + +/dev/midi00 + + + + +/dev/mixer + + + + +/dev/mixer0 + + + + +/dev/mpu401data + + + + +/dev/mpu401stat + + + + +/dev/music + + + + +/dev/rmidi0 + + + + +/dev/rtc + + + + +/dev/sequencer + + + + +/dev/smpte0 + + + + +/dev/sndstat + + + + + + + + +O que é que eu faço se o 'artsd' não arrancar ou estoirar na sua execução? + + + +Primeiro que tudo: tente usar as opções por omissão do &kcontrol; (ou se você estiver a iniciá-lo manualmente, não passe mais nenhumas opções adicionais para além de, provavelmente, a 10 4096 por causa da latência). Especialmente o 'full duplex' é provável que estoire com vários controladores, por isso tente desactivá-lo. + +Uma boa forma de perceber porque é que o &artsd; não arranca (ou se estoira em plena execução) é arrancá-lo manualmente. Abra uma janela do &konsole; e faça: + +% artsd 10 4096 + +Você poderá também adicionar a opção , a qual irá imprimir mais informações sobre o que se está a passar, como por exemplo: +% artsd 10 4096 + +Ao fazê-lo, você irá obter algumas informações úteis sobre o facto de não ter iniciado. Ou, se ele estoirar a fazer isto-ou-aquilo, você poderá fazer tal-e-tal, vendo depois como é que ele estoira. Se você quiser comunicar um erro, produza um traceamento ('backtrace') com o gdb e/ou strace para ajudar a encontrar o problema. + + + + + +É possível posicionar de novo o &artsd; (mover os ficheiros compilados para outra pasta)? + + + +Você não poderá posicionar de novo perfeitamente o &arts;. O problema é que o &artswrapper; tem a localização do &artsd; compilada por motivos de segurança. Você poderá, no entanto, usar o ficheiro .mcoprc (itens TraderPath/ExtensionPath) para fazer com que o &artsd; posicionado de novo encontre os seus componentes. Veja o capítulo sobre o ficheiro .mcoprc para saber mais detalhes sobre como fazer isto. + + + + + +Como é que posso compilar o &arts; com o gcc-3.0? + + + +Resposta curta: não, o &arts; não irá funcionar se você compilar com o gcc-3.0. + +Resposta longa: Na versão oficial existem dois erros do gcc-3.0 que afectam o &arts;. O primeiro, que é o c++/2733 do gcc-3.0 é relativamente inofensivo (e tem a ver com problemas na instrução 'asm'). Ele quebra a compilação do 'convert.cc'. Foi corrigido na versão de CVS do gcc-3.0, e não será mais um problema no gcc-3.0.1 e superiores. Foi também adicionado uma solução de recurso à versão de CVS do KDE/aRts. +O segundo erro do gcc-3.0, o c++/3145 (que consiste na geração de código errado no caso de herança múltipla virtual) é crítico. As aplicações como o &artsd; irão simplesmente estoirar no arranque quando forem compiladas com o gcc-3.0. Mesmo que tenha sido feito algo na versão do gcc-3.0 na altura em que isto foi escrito, o &artsd; continua ainda a estoirar com frequência e imprevisivelmente. + + + + +Que aplicações correm usando o &arts;? + + + +Obviamente, todas as aplicações que vêm incluídas no &kde; sabem do &arts;. Isto inclui: + + +&noatun; +&arts-builder; +&aktion; +&kmid; +&kmidi; +&kmix; +&kscd; +Os jogos do &kde;, como o &kpoker; e o &ktuberling; + + +Algumas aplicações do &kde; que não estão ainda incluídas na distribuição do &kde; (⪚, no 'kdenonbeta') também suportam o &arts;, incluindo: + + +&brahms; +Kaboodle +Kdao + + +As seguintes aplicações não-&kde; também são conhecidas por funcionar com o &arts;: + + +xmms (com o 'plugin' do &arts;) +RealPlayer 8.0 da Real Networks (funciona com o &artsdsp;; o suporte nativo do &arts; está a ser considerado) + + +Sabe-se que as seguintes aplicações não funcionam com o &arts;: + + +nenhuma + + +Veja também as respostas às perguntas na secção sobre as aplicações não-&arts;. + +Esta secção está incompleta -- se você tiver mais informações sobre as aplicações suportadas e não suportadas, por favor envie as suas referências para o autor, para que possam ser incluídas aqui. + + + + + + +Aplicações não-&arts; + + + +Assim que o &kde; começa a correr, mais nenhuma aplicação consegue aceder ao meu dispositivo de som! + + +Desde que o servidor de som &arts; que é usado pelo &kde; começa a correr, irá começar a usar o dispositivo de som. Se o servidor estiver inactivo durante 60 segundos, ele suspender-se-á e libertar o dispositivo automaticamente. + + + + + +Você diz que ele se suspende ao fim de 60 segundos, mas não o faz para mim! + + +Se você iniciar o 'artsd' a partir do painel de controlo do KDE, a situação por omissão é ele suspender-se ao fim de 60 segundos. Se você iniciar o 'artsd' a partir da linha de comandos, você precisa de usar a opção '-s' para indicar o tempo de suspensão automática, caso contrário ele irá desactivar a função de suspensão automática. +De momento, ele não se suspende se você estiver a usar o 'full-duplex'. Desactive-o no &kcontrol; e ele suspender-se-á. A desactivação do 'full-duplex' é normalmente uma boa ideia se você só usar o &arts; para tocar áudio e não para gravar. + + + + + +Como é que posso correr as aplicações antigas e que não conhecem o &arts;? + + + +Corra-as, utilizando o &artsdsp;. Por exemplo, se você normalmente iria executar: + +% mpg123 + +use em alternativa: + +% artsdsp + +Isto irá redireccionar a saída de som para o &arts;. Este método não obriga a alterações nas aplicações. É uma espécie de 'truque sujo' e ainda não suporta por completo todas as funcionalidades do dispositivo da placa de som, como tal algumas aplicações não funcionam. + + + + + +Não consigo executar o &artsdsp; com nenhuma aplicação; ela estoira sempre! + + +Você precisa de uma versão recente da biblioteca 'glibc'; o &artsdsp; não irá funcionar convenientemente em algumas distribuições mais antigas do &Linux;. Por exemplo no Debian 2.1 (que é baseado na 'glibc' 2.0) não funciona, enquanto que no Debian 2.2 (que se baseia na 'glibc' 2.1.3), funciona. + + + + + +Existem limitações teóricas com algumas aplicações que farão com que elas não corram de todo com o &artsdsp;? + + +Não. A utilização do &artsdsp; poderá dar origem a uma maior latência e utilização do CPU do que usando directamente as APIs do &arts;. Para além disso, qualquer aplicação que não funcione deverá ser considerada como manifestando algum erro no &artsdsp;. A técnica usada pelo &artsdsp; deverá, se for implementada correctamente, permitir a todas as aplicações correrem com ela (incluindo aplicações grandes como o Quake 3). + + + + + +O que é que posso fazer se uma aplicação não funcionar com o &artsdsp;? + + +Você poderá esperar que o &artsd; se suspenda ou utilizar o comando artsshell para pedir ao servidor para se suspender ele próprio. Você só poderá suspender o servidor se nenhuma das aplicações do &arts; esteja de momento a usá-lo; da mesma forma, nenhuma das aplicações do &arts; será capaz de correr quando o servidor estiver suspenso. + +Se o servidor estiver ocupado, uma maneira crua mas efectiva de se ver livre dele é: + + +% killall ; killall +Agora inicie a sua própria aplicação. +% kcminit + + +Qualquer uma das aplicações do &arts; em execução poderá estoirar, todavia, se você matar o servidor. + + + + +Então e as aplicações feitas para o &kde; 1.x? + + +Se você estiver a correr aplicações do &kde; 1.x, cuja saída de som é feita através do servidor de som do &kde; 1, você terá de correr o kaudioserver para que ele funcione. Você poderá iniciar o kaudioserver da mesma forma que as outras aplicações que não usam o &arts;: + +% artsdsp + + +Você terá de ter instalado o 'kaudioserver' (a partir do mesmo local onde arranjou as suas aplicações do &kde; 1.x) - isso pertence ao &kde; 1.x, não ao &kde; 2. + + + + + +E as aplicações que usam o servidor de som ESD (Enlightened Sound Daemon)? + + +A questão é semelhante à do kaudioserver. Essas aplicações irão necessitar de um servidor 'esd' em execução. Você poderá iniciar o esd através do &artsdsp;, e todas as aplicações que usam o ESD deverão funcionar bem, como o seguinte: +% artsdsp + +As versões mais novas do aRts ( +>= 1.2.0) também poderão usar o ESD em vez de aceder directamente à placa de som. Na linha de comandos, você poderá usar a opção '-a', tal como se segue +% artsd + +para ter o suporte do EsounD; no caso do KDE, você poderá usar o &kcontrol; para configurar o 'artsd' para usar o 'esd' em Som -> Servidor de Som -> E/S de Som. + + + + + + +Latência + + + +De vez em quando oiço pausas curtas ao ouvir música, isso é um erro? + + +Isto é provável que não seja um erro, mas seja causado pelo facto de que o 'kernel do &Linux; não é muito bom no escalonamento em tempo-real. Existem situações em que o &arts; não será capaz de se manter a tocar o som. Você poderá, contudo, activar as permissões de tempo-real (no &kcontrol;), e usar um valor de latência elevado (como por exemplo 250ms ou não interessa), o que poderá sempre melhorar a situação. + + + + + +Qual é o efeito da opção do tempo de resposta? + + +O texto de ajuda para esta opção no &kcontrol; poderá ser enganador. Um valor mais baixo significa que o &arts; irá levar menos tempo a responder aos eventos externos (&ie;. o tempo que leva entre fechar uma janela e ouvir um som tocado pelo &artsd;). Irá também usar mais recursos do CPU e estará mais sujeito a provocar perdas. + + + + + +Existe mais alguma coisa que eu possa fazer para evitar as pausas? + + +Para os utilizadores de unidades IDE, você poderá usar o comando hdparm para colocar as suas unidades IDE no modo DMA. Uma palavra de aviso: isto não funciona em todo o 'hardware', e poderá dar origem a uma reinicialização forte ou, em casos raros, à perda de dados. Leia a documentação sobre o comando hdparm para obter mais detalhes. Foi usado com sucesso o seguinte comando: + +% hdparm /dev/hda + + +Você precisa de correr isto depois de cada arranque, por isso você poderá querer colocar isto num programa de arranque do sistema (como isso é feito depende da distribuição, mas no Debian &Linux; é normalmente colocado no /etc/rc.boot). + + + + + +A prioridade de tempo-real não parece ter nenhum efeito em mim. Porquê? + + +Verifique se o 'artswrapper' está mesmo instalado 'suid' root, como é suposto que esteja. Muitas distribuições (como por exemplo o SuSE7.x) não fazem isto. Você poderá verificar isto se usar: ls -l $(which artswrapper). Bem: +% ls $(which artswrapper) +-rwsr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde3/bin/artswrapper + Mal: +% ls $(which artswrapper) +-rwxr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde3/bin/artswrapper + Se você não tiver um 's', poderá obtê-lo se fizer: % chown $(which artswrapper) +% chmod $(which artswrapper) + + + +Se você tornar o &artswrapper; SUID root, ele irá provavelmente melhorar a qualidade da sua reprodução áudio, reduzindo os cortes na música. Contudo, aumenta também o risco de que um erro no código ou um utilizador malicioso façam estoirar ou prejudicar o seu sistema. Para além disso, nas máquinas multi-utilizador, a definição de prioridades de áudio de alta-fidelidade poderá resultar numa 'performance' mais reduzida para os utilizadores que estão a tentar tirar partido produtivo da máquina. + + + + + + + +Porque é que o &artsd; está a ocupar tanto tempo de CPU? + + +Verifique a configuração do seu tempo de resposta. Contudo, a versão actual não está ainda realmente optimizada. Isto irá melhorar, e até lá, não há uma previsão real de quão rápido poderá o &artsd; ser ou não. + + + + + +Transparência na Rede + + + +O que é que preciso para a transparência na rede? + + +Active-a na configuração do Servidor de Som no &kcontrol; (activar o servidor de X11 para a informação de segurança e a transparência na rede). Depois copie o seu ficheiro .mcoprc para todas as máquinas onde você pensa usar a transparência na rede. Ligue-se de novo. Certifique-se que as máquinas que interagem conhecem as outras pelo seu nome (&ie; se elas têm nomes que possam ser resolvidos ou que se encontrem no /etc/hosts). + +Isto deverá ser tudo o que precisa de fazer. Contudo, se continuar a não funcionar, existem ainda uns detalhes adicionais. O processo do servidor de som &arts;, o &artsd;, deverá só correr numa máquina, a que tem a placa de som onde o áudio deverá ser reproduzido. Poderá ser iniciado automaticamente no arranque pelo &kde; (se configurar isso no &kcontrol;) ou manualmente, se usar algo do género: + +% artsd 5 8192 + + +A opção é para a transparência na rede, enquanto que as outras configuram a latência. + +O seu ficheiro .mcoprc deverá ter este item: + +GlobalComm=Arts::X11GlobalComm + + +em todas as máquinas envolvidas, para que a transparência na rede funcione. Isto é o que fica activo pela opção do painel de controlo servidor de X11 para a informação de segurança. + +Finalmente, em qualquer versão do &kde; da série 2.0.x, existe um erro que se aplica se você não tiver um nome de domínio definido. Os clientes do &artsd; tentam descobrir onde se ligam através da combinação maquina.dominio. Se o seu nome de domínio estiver em branco, ele irá tentar ligar-se à maquina. (repare no ponto extra). Se adicionar uma linha deste tipo ao /etc/hosts (&ie; orion., se a sua máquina se chamar orion), dará a volta ao problema. + + + + + + +Como é que eu faço depuração da transparência da rede se não funcionar? + + +Assumindo que você tem o código-fonte do &kde;, vá a kdelibs/arts/examples e execute o comando make para compilar alguns programas, incluindo o referenceinfo. Depois execute + +% ./referenceinfo + + +O resultado irá indicar o nome da máquina e do porto que está a ser usado pelo &arts;. Por exemplo, tcp:orion:1698 significa que qualquer cliente que tente usar a transparência de rede deverá saber como aceder à máquina orion. + + + + + + +Perguntas específicas do 'hardware' + + + +Com que 'hardware' o 'artsd' não funciona bem? + + +Parece que existem alguns controladores de &Linux; que não funcionam bem com o &arts; em algumas versões do 'kernel'. Por favor, veja esta lista antes de relatar algum erro. Se você achar que alguma da informação desta lista está incompleta, por favor não hesite em dar-nos a conhecer. + + +Controlador do Linux / Placa de Som +Não funciona em +Funciona em +Comentários + + + + + +controlador i810 (Intel 810 + Áudio AC97) +2.4.9 +2.4.18, 2.2.20, controlador comercial do oss, alsa-0.5.12a com emulação de OSS +o controlador provoca sobrecarga do CPU (ver em baixo) + + + +'chipset' Maestro 3/4 +2.4.9 +? +o controlador provoca algumas vezes sobrecarga do CPU (ver em baixo) + + + +controladores do aureal8820, aureal8830 do Sourceforge +2.4.17 +? +o controlador lança excepções / causa sobrecarga do CPU (ver em baixo) + + + +OSS Comercial 3.9.4g com Vértice Aural +? +? +bloqueio do sistema + + + +ymfpci +2.4.0, 2.4.12 +2.4.17 +o controlador lança uma excepção (ver em baixo) + + + + + + + + + + + + + + + +Porque é que existem problemas específicos do 'hardware' e como é que os vejo? + + +O problema normal é que o controlador não fornece ao aRts a informação suficiente ou a correcta sobre quando deve escrever os dados do som. A maioria dos controladores do OSS fornecem a informação correcta, mas nem todos. +Você poderá reparar que algumas das outras aplicações (como o 'xmms') poderão não necessitar desses dados, e poderão deste modo até funcionar correctamente com o seu 'hardware'. Contudo, o &arts; precisa destes dados, por isso o 'artsd' poderá falhar. Isto é à mesma um erro no controlador e não do &arts;. +Existem dois tipos de comportamento que o 'artsd' expõe ao ser executado num controlador incorrecto. Ou ele tenta continuamente fornecer dados novos, mas nunca consegue de facto ser bem-sucedido, o que poderá levar eventualmente a que consuma todo o poder de processamento do CPU e acuse sobrecarga do CPU e saia. Ou então, o outro problema é que o 'artsd' poderá ser notificado com informações erradas sobre quanto deverá escrever. O 'artsd' irá então tentar parar com uma excepção do género: artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int): +Assertion `len == can_write' failed (A excepção 'len == can_write' falhou) +Aborted (Interrompido) + + + + + + + +O que é que se passa no controlador se eu tiver o problema da sobrecarga do CPU?? + + +Normalmente, o 'artsd' usa o select() para tentar descobrir quando é que deverá escrever dados novos. Depois usa um ioctl(...GETOSPACE...) para saber quantos mais dados deverá escrever. Finalmente, ele irá escrever esses dados. +Ocorre um problema se o 'artsd' é acordado sempre ou se existem quantidades pequenas de dados para escrever. A documentação do OSS diz que o select() só acorda um processo se existir pelo menos um fragmento para escrever. Contudo, se o 'artsd' é acordado e não existem dados para escrever ou são muito poucos, como por exemplo uma amostra, então ele irá continuar a escrever pedaços pequenos de dados de áudio, o que se poderá tornar muito dispendioso e, eventualmente, sobrecarregará o CPU. +Para resolver isto, o controlador deverá acordar o 'artsd' apenas se existir um fragmento completo para escrever. + + + + + +O que se passa de errado no controlador se eu obtiver a excepção? + + +Normalmente, o 'artsd' usa o select() para tentar descobrir quando é que deverá escrever dados novos. Depois usa um ioctl(...GETOSPACE...) para saber quantos mais dados deverá escrever. Finalmente, ele irá escrever esses dados. +Se o 'artsd' não consegue escrever tantos dados quantos são indicados pelo 'ioctl', ele irá falhar com a excepção. Para resolver isto, o controlador deverá indicar a quantidade de espaço livre correcta. + + + + + +Outros Problemas + + + +Não consigo usar o &arts-builder;. Ele estoira ao executar um módulo! + + +A causa mais provável será porque você está a usar estruturas ou módulos antigos que não são suportados na versão do &kde; 2. Infelizmente, a documentação que se encontra na Web refere-se ao &arts;-0.3.4.1, o qual está bastante desactualizado. O estoiro mais frequentemente relatado é: ao executar uma estrutura no &arts-builder; resulta na mensagem de erro [artsd] Synth_PLAY: audio subsystem is already used (o sub-sistema de áudio já está em uso). + +Você deverá usar um módulo Synth_AMAN_PLAY em vez de um Synth_PLAY, para que o problema se vá embora. Veja também o ficheiro de ajuda do &arts-builder; (carregue em F1 no &arts-builder;). + +As versões mais recentes do &arts-builder; (do &kde; 2.1 beta 1 e posteriores) vêm com um conjunto de exemplos que você poderá usar. + + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/future.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/future.docbook new file mode 100644 index 00000000000..96886e88f2c --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/future.docbook @@ -0,0 +1,401 @@ + + + +Trabalho Futuro + +Esta secção descreve algum do trabalho do &arts; que se encontra em progresso. O desenvolvimento progride rapidamente, por isso esta informação poderá estar desactualizada. Você deverá ver o ficheiro da lista TODO e os arquivos das listas de correio para ver quais as novas funcionalidades que estão planeadas. Sinta-se à vontade para se envolver no novo desenho e implementação. + +Este é um rascunho do documento que lhe tenta dar uma ideia geral de como as novas tecnologias serão integradas no &arts;. Nomeadamente, cobre o seguinte: + + +Como é que as interfaces funcionam. +Codificadores - a descodificação de sequências de MP3 ou WAV num formato em que possam ser usados como dados. +Vídeo. +Multi-tarefa. +Sincronização. +Expansão/máscara dinâmicas. +Composição dinâmica. +&GUI; +&MIDI; + + +Isto ainda é trabalho em progresso. Contudo, deverá ser a base se você quiser ver tecnologias novas no &arts;. Ele dever-lhe-á dar uma ideia geral de como esses problemas serão tratados. Contudo, sinta-se à vontade para corrigir tudo o que verá aqui. + +As coisas que serão utilizadas pela tecnologia do &arts; (por isso, coordenem os vossos esforços): + + + +KPhone (voz sobre IP) + + + +&noatun; (leitor de áudio / vídeo) + + + +&artscontrol; (programa de controlo do servidor de som, para os âmbitos) + + + +Brahms (sequenciador de música) + + + +Kaiman (leitor multimédia do &kde;2 - compatível com o kmedia2) + + + +mpglib/kmpg (tecnologia de reprodução de áudio e vídeo mpg) + + + +SDL (camada multimédia directa para jogos que ainda não começou, mas que se tornará óptima) + + + +electric ears (o autor contactou-me - o estado é desconhecido) + + + + +Como Funcionam as Interfaces + + + +As interfaces do &MCOP; são a base do conceito do &arts;. Elas são o equivalente transparente na rede das classes de C++. Sempre que possível, você deverá orientar o seu desenho para as interfaces. Estas consistem em quatro partes: + + +Sequências síncronas +Sequências assíncronas +Métodos +Atributos + + +Estes poderão ser misturados da forma que você desejar. As novas tecnologias deverão ser definidas em termos de interfaces. Leia as secções sobre as sequências assíncronas e síncronas, assim como as interfaces do KMedia2, os quais são um bom exemplo sobre como as coisas funcionam + +As interfaces são especificadas no código .idl e executadas através do compilador mcopidl. Você deriva da classe NomeInterface_impl para as implementar e usa a função REGISTER_IMPLEMENTATION(NomeInterface_impl) para inserir as implementações do seu objecto no sistema de objectos do &MCOP;. + + + + +Codificadores - Descodificação de Dados + +As interfaces do 'kmedia2' permitem-lhe ignorar que os ficheiros WAV, MP3 entre outros consistem em sequências de dados. Em alternativa, você só implementa os métodos para os tocar. + +Deste modo, você poderá criar uma rotina de carregamento de WAVE's de forma a que você possa tocar ficheiros WAVE (como PlayObject), mas mais ninguém pode usar o seu código. + +As sequências assíncronas seriam a alternativa. Você define uma interface que lhe permite passar os blocos de dados para dentro extrair blocos de dados para fora. Isto parece ser mesmo assim no &MCOP;: + +interface Codificador { + entrada async byte stream indata; + saida async byte stream outdata; +}; + + + +Claro que os codificadores também poderão fornecer parâmetros para emitir dados adicionais, tais como a informação do formato. + +interface CodificadorAudioByte { + entrada async byte stream indata; + saida async byte stream outdata; + readonly attribute amostragem, bits, canais; +}; + + +Este CodificadorAudioByte, por exemplo, poder-se-ia ligar a um objecto ByteStreamToAudio para suportar áudio de vírgula flutuante. + +Claro, outros tipos de codificadores poderiam envolver directamente a emissão de dados de vídeo, como por exemplo + +interface CodecVideo { + entrada async byte stream indata; + saida video stream outdata; /* nota: as sequências de vídeo ainda não existem */ +}; + + +Muito provavelmente, o conceito de um codificador deveria se aplicado em vez da forma você sabe como tocar e eu não como, por exemplo, o WavPlayObject usa no momento. Contudo, alguém precisa de parar e fazer algumas experiências antes de API API ser finalizada. + + + + +Vídeo + +A ideia é fornecer o vídeo como sequências assíncronas de algum tipo de dados nativo do &MCOP; que contenha imagens. Este tipo de dados ainda está por ser criado. Ao fazê-lo, os 'plugins' que lidem com as imagens de vídeo poderão ser ligados da mesma forma que os 'plugins' de áudio. + +Existem algumas coisas que são importantes não deixar de fora, nomeadamente: + + + +Existem os espaços de cores RGB e YUV. + + +O formato deverá ser associado de qualquer forma à sequência. + + +A sincronização é importante. + + + +A ideia é deixar possível a reimplementação da classe VideoFrame (ImagemVideo) para que possa armazenar a informação num segmento de memória partilhada. Ao fazê-lo, até a difusão de vídeo entre os diferentes processos seria possível sem muito trabalho. + +Contudo, a situação normal para o vídeo é que as coisas estão todas no mesmo processo, desde a descodificação até ao desenho. + +Foi feita uma implementação em protótipo de emissão de vídeo, a qual poderá obter aqui. Isto teria de ser integrado no &MCOP; ao fim de algumas experiências. + +Uma componente de desenho deveria ser fornecida que suportasse o XMITSHM (com o RGB e o YUV); o Martin Vogt comunicou que estava a fazer algo do género. + + + + +Multitarefa + +De momento, o &MCOP; é todo ele monotarefa. Talvez para o vídeo não seja mais possível dar a volta a essa questão. Ok. Existem algumas coisas que têm de ser tratadas com cuidado: + + + +SmartWrappers - estes não são seguros em multitarefa devido à contagem de referências insegura, entre outras questões similares. + + +'Dispatcher' / E/S - Também inseguros em multitarefa. + + + +Contudo, o que é possível imaginar é tornar os módulos seguros em multitarefa para ambos os casos de sequências, síncronas e assíncronas. Desta forma - com um sistema de fluxo que suporte multitarefa, você poderá escalonar o fluxo do sinal por dois ou mais processadores. Isto iria ajudar bastante no áudio em sistemas multi-processador. + +Como iria funcionar: + + + + +O Sistema de Fluxo decide que módulos deverão calcular o quê - isto é: + + imagens de vídeo (com o método 'process_indata') + sequências de áudio síncronas ('calculateBlock') + outras sequências assíncronas, nomeadamente sequências de 'bytes' + + + +Os módulos poderão calcular estas coisas em tarefas próprias. Para o áudio, faz sentido reutilizar as tarefas (⪚ aplicar em quatro tarefas por quatro processadores, independentemente de estarem a correr 100 módulos). Para a descompressão de vídeo e de 'bytes', poderá ser mais confortável ter uma implementação bloqueante numa tarefa própria, a qual está sincronizada com o resto do &MCOP; pelo sistema de fluxo. + + + +Os módulos não poderão usar a funcionalidade do &MCOP; (como as invocações remotas) durante a operação multitarefa. + + + + + + +Sincronização + +O vídeo e o &MIDI; (e o áudio) poderão necessitar de sincronização. Basicamente, baseia-se em marcas temporais. A ideia que existe é anexar as marcas temporais às sequências síncronas, adicionando esse campo a cada pacote. Se você enviar duas imagens de vídeo, simplesmente crie dois pacotes (eles são grandes, de qualquer forma), por isso poderá ter duas marcas temporais diferentes. + +O áudio deverá ter implicitamente marcas temporais, dado que é síncrono. + + + + +Composição Dinâmica + +Deveria ser possível dizer: um FX de efeito é composto a partir destes módulos mais simples. O FX deverá funcionar como um módulo de &MCOP; normal (veja a máscara), mas de facto consiste noutros módulos. + +Isto é necessário para o &arts-builder;. + + + + +&GUI; + +Todos os componentes &GUI; serão módulos do &MCOP;. Eles deverão ter atributos do tipo 'size' (tamanho), 'label' (texto), 'color' (cor), ... . Um construtor RAD (como o &arts-builder;) deverá ser capaz de os compor visualmente. + +A &GUI; deverá ser gravável, ao registar os atributos. + + + + +&MIDI; + +A funcionalidade do &MIDI; será implementada como sequências assíncronas. Existem duas opções, em que uma usa estruturas normais de &MCOP; para definir os tipos e o outro para introduzir ainda outros tipos personalizados. + +Pensa-se que as estruturas normais serão suficientes, isto é, algo do tipo: + +struct EventoMidi { + byte b1,b2,b3; + sequence<byte> existe; +} + + +As sequências assíncronas deverão suportar os tipos de sequências personalizados. + + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/glossary.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/glossary.docbook new file mode 100644 index 00000000000..97fe21f5473 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/glossary.docbook @@ -0,0 +1,177 @@ + + + + + +ALSA + +Advanced &Linux; Sound Architecture (Arquitectura de Som Avançada do &Linux;); um controlador de placas de som do &Linux;, e que não vem incluída de momento no código-fonte normal do 'kernel'. + + + + +&arts; + +Analog Real-Time Synthesizer (Sintetizador em Tempo-Real Analógico); o nome da arquitectura/biblioteca/ferramenta multimédia que é usada pelo projecto do &kde; (repare na capitalização) + + + + +BSD + +Berkeley Software Distribution (Distribuição de 'Software' da Berkeley); aqui refere-se a qualquer um dos sistemas operativos livres e compatíveis com o &UNIX;, que derivam do &UNIX; da BSD. + + + + +CORBA + +Common Object Request Broker Architecture (Arquitectura de Mediação de Pedidos de Objectos Comuns); uma norma para implementar a execução remota orientada por objectos. + + + + +CVS + +Concurrent Versions System (Sistema Concorrente de Versões); um sistema de gestão de configurações de 'software' que é usado por muitos projectos de sistemas, e que inclui o &kde; e o &arts;. + + + + +FFT + +Fast Fourier Transform (Transformada de Fourier Rápida); um algoritmo para converter dados do domínio do tempo para o da frequência; é usado frequentemente no processamento de sinais. + + + + +Full Duplex + +A capacidade de uma placa de som gravar e reproduzir áudio em simultâneo. + + + + +GPL + +GNU General Public License (Licença Pública Geral da GNU); uma licença de 'software' criada pela Free Software Foundation para definir os termos para lançar 'software' livre. + + + + +&GUI; + +Interface Gráfica com o Utilizador + + + + +IDL + +Interface Definition Language (Linguagem de Definição de Interfaces); uma linguagem de programação que é independente do formato para especificar as interfaces (os métodos e os dados). + + + + +&kde; + +K Desktop Environment (Ambiente de Trabalho K); um projecto para desenvolver um ambiente de trabalho gráfico livre para os sistemas compatíveis com o &UNIX;. + + + + +LGPL + +GNU Lesser General Public License (Licença Pública Geral Lata da GNU; uma licença de 'software' criada pela Free Software Foundation e que define os termos para lançar 'software' livre; é menos restrita que a GPL e é usada com frequência pelas bibliotecas de 'software'. + + + + +&MCOP; + +Multimedia COmmunication Protocol (Protocolo de Comunicação Multimédia); o protocolo usado para a comunicação entre os módulos de 'software' do &arts;; é semelhante ao CORBA mas é mais simples e é optimizado para o multimédia. + + + + +&MIDI; + +Musical Instrument Digital Interface (Interface Digital de Instrumentos Musicais); um protocolo-padrão para comunicar entre os instrumentos musicais electrónicos; é usado também normalmente para se referir a um formato de ficheiros que armazena os comandos &MIDI;. + + + + +OSS + +Open Sound System (Sistema de Som Aberto); os controladores de som que vêm incluídos no 'kernel' do &Linux; (normalmente chamado de OSS/Free) ou uma versão comercial que é vendida pela 4Front Technologies. + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/gui.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/gui.docbook new file mode 100644 index 00000000000..b769c161b6b --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/gui.docbook @@ -0,0 +1,29 @@ + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/helping.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/helping.docbook new file mode 100644 index 00000000000..1a50cb5fadd --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/helping.docbook @@ -0,0 +1,237 @@ + + + +Contribuir para o &arts; + + +Como Pode Ajudar + +O projecto do &arts; poderá usar a ajuda dos programadores para tornar as aplicações multimédia cientes do &arts;, criar aplicações multimédia novas e melhorar as capacidades do &arts;. Contudo, você não terá de ser um programador para contribuir. A ajuda também poderá ser usada para as pessoas dos testes para enviarem relatórios de erros, traduções do texto e da documentação das aplicações para outras línguas, artistas para desenharem imagens (especialmente para os módulos do artsbuilder), músicos para criarem módulos de amostras do &arts; e escritores para criarem ou validarem a correcção da documentação. + + + +Listas de Correio + +A maioria das discussões de programação do &arts; tomam lugar em duas listas de correio. Este é o lugar para discutir as novas ideias de funcionalidades e de implementação, ou para pedir ajuda para alguns problemas. + +A lista de correio de Multimédia do &kde; é para os assuntos gerais de multimédia do &kde;, e que inclui o &arts;, assim como as aplicações multimédia, como o &noatun; e o &aktion;. Você poder-se-á subscrever na página Web em http://www.kde.org/mailinglists.html ou enviar uma mensagem de e-mail com o assunto igual a subscribe o-seu-endereço-de-e-mail para kde-multimedia-request@kde.org. A lista está também arquivada em http://lists.kde.org. + +A lista de correio do &arts; é para os assuntos específicos do &arts;, incluindo a utilização fora do &kde; do &arts;. Para se subscrever, envie uma mensagem de e-mail que contenha o corpo da mensagem subscribe o-seu-endereço-de-e-mail para arts-request@space.twc.de. A lista é arquivada em http://space.twc.de/~stefan/arts-archive. + + + + +Normas de Código + +Para obter uma leitura consistente de todo o código, é importante manter o estilo de código igual entre si em todo o código do &arts;. Por favor, mesmo que você só crie um módulo, tente escrever/formatar o seu código de acordo com as recomendações, para que facilite para as várias pessoas manterem a estrutura de código e para ser mais fácil de copiar pedaços de código de um bloco para outro. + + + +Nome das funções-membro + +Estilo do &Qt;/&Java;. Isso equivale à capitalização nas quebras de palavras, tendo a primeira letra em minúsculas; sem sublinhados. +Isto significa, por exemplo: + +criarDescrEstrutura() + actualizarItem(); + iniciar(); + + + + + +Membros da classe + +Os membros da classe não são capitalizados, como por exemplo 'barramenu' ou 'botao'. + +Quando existirem funções de acesso, a norma deverá ser a do &MCOP;, isto é, ao ter um membro 'long' xpto, o qual não será visível directamente, você cria funções: + +xpto(long novo_valor); + long xpto(); + +para obter e alterar o valor. Nesse caso, o valor real de xpto serão armazenadas em _xpto. + + + + +Nomes das classes + +Todas as classes deverão ser capitalizadas nas palavras, o que significa JanelaModulo, ModuloSintese. Todas as classes que pertencem às bibliotecas deverão usar o espaço de nomes do &arts;, como o Arts::Soundserver. +As implementações das classes do &MCOP; dever-se-ão chamar Classe_impl, como por exemplo ServidorSom_impl. + + + + +Parâmetros + +Os parâmetros nunca estão capitalizados. + + + + +Variáveis locais + +As variáveis locais nunca são capitalizadas, e poderão ter nomes do tipo i, p, x, &etc;, sempre que apropriado. + + + + +Tamanho da tabulação + +Uma tabulação equivale neste caso a 4 espaços. + + + + +Espaços nas expressões + +Você não precisa normalmente de usar espaços nas expressões. Você poderá, no entanto, usá-los entre os operadores e os seus operandos. Todavia, se você puser um espaço antes de um operador (p.ex., o +), você também precisa de pôr um a seguir ao mesmo. A única excepção a isto são as expressões do tipo lista (com o ,), onde você deverá pôr um espaço a seguir ao ",", mas não antes. Também é aceitável omitir aqui o espaço. +Os exemplos seguintes demonstram uma boa utilização dos espaços: +{ + 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); +} + +Os exemplos seguintes demonstram como não usar os espaços. Para as chamadas as funções, a seguir ao 'if', 'while', 'for', 'switch', entre outros, não é adicionado nenhum espaço. +{ + // MAL: se você indicar uma lista, ponha espaços apenas após o "," + int a , b , c , d , e , f; + + // MAL: utilização não-simétrica dos espaços no operador '=' + a= 5; + + // MAL: se for considerada uma função, e se não for seguida de um espaço + if (a == 5) { + } + + // MAL: não colocar um espaço a seguir ao 'while' + while (a--) + b++; + + // MAL: os nomes das funções não são seguidos de um espaço + arts_debug ("%d\n", c); + + // MAL: nada aqui é o nome de um membro + Arts::Object o = Arts::Object::null (); +} + + + + + + +Nomenclatura dos ficheiros de código + +Os ficheiros de código aqui não deverão ter capitalizações no nome. Deverão ter o nome da classe quando implementam uma única classe. A sua extensão é a .cc se se referirem ao código independente do &Qt;/&GUI;, e .cpp se se referirem ao código dependente do &Qt;/&GUI;. Os ficheiros de implementação das interfaces dever-se-á chamar xpto_impl, se o Xpto for o nome da interface. + +Os ficheiros &IDL; deverão ser chamados de uma forma descritiva para a colecção de interfaces que eles contêm, estando tudo também em minúsculas. Especialmente, não é bom chamar a um ficheiro &IDL; o nome da classe, dado que o mediador .mcopclass e os itens do tipo de informação irão colidir, nesse caso. + + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/index.cache.bz2 b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/index.cache.bz2 new file mode 100644 index 00000000000..480eb157ffe Binary files /dev/null and b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/index.cache.bz2 differ diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/index.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/index.docbook new file mode 100644 index 00000000000..3cc0c669f08 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/index.docbook @@ -0,0 +1,417 @@ + + + + + + + + + + + + + + + + + + + + MCOP"> + DCOP"> + MIDI"> + mcopidl"> + IDL"> + + +]> + + + +O Manual do &arts; + + +Stefan Westerfeld
stefan@space.twc.de
+ + + +Jeff Tranter
tranter@kde.org
+ + + +JoséPires
jncp@netcabo.pt
Tradução + + + +1999-2001 +Stefan Westerfeld & Jeff Tranter + +&FDLNotice; + +2001-06-10 +1.00.09 + +Este manual descreve o &arts;, o Sintetizador de Tempo-Real Analógico. + + + + +aRts +artsbuilder +sintetizador +multimédia +estrutura +música +som +KDE + + + + +Introdução + + +O que é o &arts;? + +O Sintetizador de Tempo-Real Analógico, ou &arts;, é um sistema modular para sintetizar o som e a música num computador digital. Usando blocos de construção pequenos chamados módulos, o utilizador poderá criar facilmente ferramentas de processamento de áudio complexas. Os módulos oferecem tipicamente funções como geradores de formas de onda, filtros, efeitos de áudio, mistura de som, reprodução de áudio digital em vários formatos de ficheiros diferentes. + +O servidor de som &artsd; mistura o áudio de várias fontes em tempo-real, permitindo a várias aplicações de som partilharem de forma transparente o acesso ao 'hardware' de som. + +Usando o &MCOP; (Multimedia Communication Protocol), as aplicações multimédia poderão ser transparentes na rede, autenticadas do ponto de vista da segurança, e multiplataforma, recorrendo à utilização de interfaces definidas de forma independente da linguagem com o &IDL;. O suporte também é fornecido para as aplicações legadas que não saibam do &arts;. Como componente de base para o ambiente de trabalho do &kde; 2, o &arts; fornece a base da arquitectura multimédia do &kde; e irá no futuro suportar outros tipos multimédia, incluindo o vídeo. Tal como o &kde;, o &arts; corre numa variedade de sistemas operativos, incluindo o &Linux; e as variantes do BSD. Pode ser usado independentemente do &kde;. + + + + +Usar Este Manual + +Este manual pretende oferecer uma documentação compreensiva sobre o &arts; aos utilizadores com diferentes níveis de aptidões. Dependendo se você é um utilizador normal de aplicações multimédia que tiram partido do &arts; ou um programador de aplicações multimédia, você poderá querer seguir caminhos diferentes ao longo do manual. + +Sugere-se que você leia primeiro o capítulo de Transferir e Compilar o &arts; se precisar de ter o &arts; instalado inicialmente e em funcionamento. Se você já tiver um sistema funcional, provavelmente incluído na distribuição do seu sistema operativo, você poderá optar por ignorar esta secção. + +Você deverá então ler as secções no capítulo das Ferramentas do &arts;, especialmente o do &artsd;, do 'artscontrol';, do '&artsshell;', e do '&artsdsp;'. Isto ajudá-lo-á a tirar o partido mais efectivo do &arts;. + +Se você estiver interessado em ir mais além com o &arts;, leia o capítulo sobre o &arts-builder; e siga ao longo do tutorial. Isto deverá dar-lhe uma apreciação global das capacidades poderosas do &arts; e dos módulos fornecidos que poderão ser usados sem haver necessidade de ser um programador. + +Se você quiser saber mais sobre os detalhes do &arts;, quer para desenvolver aplicações multimédia quer para extender o próprio &arts;, leia uma parte ou todo o capítulo O &arts; em Detalhe. Isto deverá permitir-lhe compreender todos os conceitos considerados como pré-requisitos da programação de 'software' com o &arts;. + +Se você estiver interessado especificamente nas capacidades de MIDI do &arts;, deverá ler o capítulo sobre o &MIDI;. + + + +Se quiser desenvolver aplicações multimédia que suportem o &arts;, o capítulo das Interfaces de Programação de Aplicações do &arts; cobrem as diferentes APIs em detalhe. + +Se você quiser extender o &arts;, criando para tal novos módulos, leia o capítulo dos Módulos do &arts;. + +Se estiver a modificar uma aplicação existente para correr sob o &arts;, leia o capítulo sobre Transformar Aplicações para o &arts;. + +Você poderá saber como ajudar a contribuir para o projecto do &arts; no capítulo Contribuir para o &arts;, ler sobre os próximos desenvolvimentos no capítulo sobre o Trabalho Futuro, e obter referências para mais informações na secção de Referências. + +Foi dada uma volta ao manual com algum material adicional, incluindo as respostas às perguntas mais frequentes, uma lista das contribuições, os detalhes sobre o &arts; o 'copyright' e as licenças, bem como algum material de fundo sobre o áudio digital e o &MIDI;. Está também incluído um glossário de termos. + + +Este manual ainda tem muito trabalho por fazer. Você é bem-vindo para contribuir na escrita de partes dele, mas se o quiser fazer, contacte o Jeff Tranter tranter@kde.org ou o Stefan Westerfeld stefan@space.twc.de para evitar a duplicação de esforço. + + + + + +Histórico + +No fim de 1997, o Stefan Westerfeld começou a trabalhar num sistema modular em tempo-real para a síntese de som. O código corria inicialmente num sistema PowerPC que funcionava em &AIX;. Essa implementação era muito simples, mas suportava um sistema de fluxo completo que era capaz de fazer coisas como tocar ficheiros MP3 e encaminhar os canais de áudio por módulos de efeitos. + + +O próximo passo foi implementar uma &GUI; de modo a que os módulos pudessem ser manipulados graficamente. O Stefan tem tido algumas experiências boas com o &kde;, de modo que foi escolhido como a plataforma &GUI;, (sabendo que poderá ser necessário fazer também uma versão para GNOME/Gtk+) e isto levou posteriormente a usar o &Linux; como plataforma principal de desenvolvimento. Chamado anteriormente de ksynth, o projecto mudou de nome para &arts; e a rapidez de desenvolvimento acelerou. O projecto nesta fase estava muito completo, com um protocolo baseado em CORBA, com dezenas de módulos, uma ferramenta gráfica de edição de módulos, APIs em C e C++, documentação, utilitários, páginas Web e listas de correio com um pequeno grupo de programadores. O projecto avançou bastante com pouco mais do que um ano de desenvolvimento. + +Assim que a equipa do &kde; começou a planear o &kde; 2.0, tornou-se óbvio que o &kde; necessitava de uma infra-estrutura mais poderosa para o som e para os conteúdos multimédia. Optou-se por adaptar o &arts;, dado que era um bom passo nesta direcção com uma arquitectura estável. Muito do esforço de desenvolvimento foi aplicado nesta nova versão do &arts;, sendo o mais notável a substituição do código em CORBA por um sub-sistema completamente novo, o &MCOP;, optimizado para o multimédia. A versão 0.4 do &arts; foi incluída na versão 2.0 do &kde;. + +O trabalho continua no &arts;, melhorando a performance e adicionando novas funcionalidades. Deverá ser visto que até mesmo o &arts; é agora um componente de base do &kde;, embora possa ser usado sem o &kde;, e também é usado por aplicações que vão mais além do multimédia tradicional. O projecto atraiu algum interessa da equipa do GNOME, abrindo a possibilidade a que alguma vez se torne a arquitectura-padrão do multimédia nos ambientes de trabalho do &UNIX;. + + + + + +&tools; +&artsbuilder-doc; +&detail; +&arts-midi; +&gui; +&mcop-ref; +&apis; +&modules; +&porting; +&helping; +&future; +&references; +&arts-faq; + + + +'Copyright' e Licenças do &arts; + +'Software' do &arts; copyright 1998-2001 Stefan Westerfeld stefan@space.twc.de + + Documentação copyright 1999-2001 Stefan Westerfeld stefan@space.twc.de e Jeff Tranter tranter@kde.org. +Tradução de José Nuno Pires jncp@netcabo.pt +&underFDL; Todas as bibliotecas que existem no &arts; estão licenciadas segundo os termos da licença GNU Lesser General Public. A grande maioria do código do &arts; está nas bibliotecas, incluindo todo o MCOP e o ArtsFlow. Isto permite às bibliotecas serem usadas para aplicações não-livres e não-gratuitas, se o desejar. + +Existem alguns programas (como o artsd), que são lançados segundo os termos da General Public License da GNU. Dado que têm havido algumas opiniões diferentes sobre se é legal compilar programas GPL com o &Qt;, foi adicionada também uma nota explícita que o permite, para além da GPL: a permissão está também concedida para poder compilar este programa com a biblioteca do &Qt;, tratando o &Qt; como uma biblioteca que acompanha normalmente o 'kernel' do sistema operativo, embora seja ou não esse o caso. + + + + +Instalar o &arts; + +Para poder usar o &arts; você precisa obviamente de o ter instalado e a funcionar no seu sistema. Existem duas aproximações para o fazer, as quais estão descritas nas próximas secções. + + +Instalar uma Versão Binária Pré-Compilada + +A forma mais rápida e simples de ter o &arts; a funcionar é instalando os pacotes binários pré-compilados para o seu sistema. A maioria das distribuições recentes do &Linux; incluem o &kde;, e se for o &kde; 2.0 ou posterior, irá incluir o &arts;. Se o &kde; não estiver incluído na sua instalação, poderá estar disponível para transferência a partir do fabricante do seu sistema operativo. Em alternativa, poderá está disponível a partir de terceiros. Certifique-se que você usa os pacotes que são compatíveis com a versão do seu sistema operativo. + +Uma instalação básica do &kde; irá incluir o servidor de som, o que permitirá à maioria das aplicações tocarem som. Se quiser o conjunto completo de ferramentas e aplicações multimédia, você irá provavelmente necessitar de instalar os pacotes opcionais adicionais. + +A desvantagem da utilização dos binários pré-compilados é que poderão não ser a versão mais recente do &arts;. Isto provavelmente será o caso se eles forem fornecidos num &CD-ROM;, dado que a rapidez do desenvolvimento do &arts; e do &kde; é tal que a disponibilização em &CD-ROM; não costuma acompanhar esse ritmo. Você poderá concluir também que, se tiver uma arquitectura ou uma distribuição menos comum, os pacotes binários pré-compilados poderão não estar disponíveis e, aí, você terá de usar o segundo método. + + + + +Compilar o Código + +Embora ocupe algum tempo, a forma mais flexível de criar o &arts; é compilar você próprio o código-fonte. Isto garante-lhe que tem uma versão compilada de forma óptima para a sua configuração do sistema e permite-lhe ter a versão mais recente. + +Você tem aqui duas opções -- tanto poderá instalar a versão estável mais recente que vem incluída com o &kde; ou poderá obter directamente a versão mais recente (mas possivelmente instável) a partir do repositório de CVS do &kde;. A maioria dos utilizadores que não estejam a programar para o &arts; deverão usar a versão estável. Você poderá obtê-la em ftp://ftp.kde.org ou numa das suas réplicas. Se você estiver a programar activamente para o &arts; você irá querer usar provavelmente a versão no CVS. Se quiser usar o aRts sem o KDE, você poderá obter uma versão autónoma de desenvolvimento em http://space.twc.de/~stefan/kde/arts-snapshot-doc.html. + +Tenha em atenção que, se tiver a compilar a partir do CVS, algumas das componentes do &arts; (&ie; as componentes de base que incluem o servidor de som) estão no módulo do CVS 'kdelibs', enquanto que os componentes adicionais (⪚ o artsbuilder) estão incluídos no 'kdemultimedia'. Isto poderá mudar no futuro. Você poderá também encontrar uma versão no módulo 'kmusic'; esta é a versão antiga (antes do &kde; 2.0) e que está agora obsoleta. + +Os requisitos para compilar o &arts; são basicamente os mesmos que para compilar o &kde;. Os programas do 'configure' deverão detectar a configuração do seu sistema e indicar se estão a faltar alguns componentes obrigatórios. Certifique-se que tem um controlador de som a funcionar no seu sistema (seja ele o OSS/Free que vem com o 'kernel', o controlador OSS da 4Front Technologies, ou o ALSA com a emulação do OSS). + +Poderá obter mais informações sobre como obter e instalar o &kde; (incluindo o &arts;) na &FAQ; do &kde;. + + + + + +&digitalaudio; +&midiintro; +&arts-glossary; + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/mcop.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/mcop.docbook new file mode 100644 index 00000000000..dc8900496a7 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/mcop.docbook @@ -0,0 +1,1974 @@ + + + +&MCOP;: Modelo de Objectos e Transmissão + + + +Introdução + +O &MCOP; é a norma que o &arts; usa para: + + + +A comunicação entre os objectos. + + + +A transparência na rede. + + + +A descrição das interfaces dos objectos. + + + +A independência da linguagem. + + + +Um aspecto importante do &MCOP; é a linguagem de descrição de interfaces, ou &IDL;, na qual muitas das interfaces do &arts; e as APIs estão definidas de forma independente da linguagem. + +Para usar as interfaces de &IDL; a partir do C++, é compilada pelo compilador de &IDL; em código de C++. Quando você implementar uma interface, você irá derivar da classe de esqueleto que o compilador de &IDL; gerou. Quando usar uma interface, você irá fazer isso através de uma classe envolvente ('wrapper'). Desta forma, o &MCOP; pode usar um protocolo se o objecto com quem você está a falar não estiver local - você obtém assim a transparência de rede. + +Este capítulo é suposto descrever as funcionalidades básicas do modelo de objectos que resulta da utilização do &MCOP;, o protocolo, como usar o &MCOP; no C++ (interface para a linguagem), e assim por diante. + + + + + +As interfaces e a &IDL; + +Muitos dos serviços fornecidos pelo &arts;, como os módulos e o servidor de som, são definidos com base em interfaces. As interfaces são especificadas num formato independente de linguagens: a &IDL;. + +Isto permite que muitos dos detalhes de implementação, como o formato das sequências de dados multimédia, a transparência de rede e as dependências de linguagens de programação, sejam escondidos da especificação da interface. Uma ferramenta, o &mcopidl;, traduz a definição da interface para uma linguagem de programação específica (de momento, só o C++ é que é suportado). + +A ferramenta gera uma classe-esqueleto com todo o código de 'cola' e a funcionalidade de base. Você pode derivar a partir dessa classe para implementar as funcionalidades que deseja. + +A &IDL; usada pelo &arts; é semelhante à usada pelo CORBA e pelo DCOM. + +Os ficheiros &IDL; podem conter: + + + +Directivas #include do estilo do C para outros ficheiros &IDL;. + + + +Definições de tipos enumerados e estruturas, como no C/C++. + + + +Definições de interfaces. + + + +Na &IDL;, as interfaces são definidas de forma muito semelhante à de uma classe de C++ ou de uma estrutura do C, ainda que com algumas restrições. Como no C++, as interfaces podem ser subclasses de outras interfaces através de herança. As definições de interfaces podem incluir três coisas: sequências, atributos e métodos. + + + +Sequências + +As sequências ou canais definem os dados multimédia, um dos componentes mais importantes de um módulo. As sequências são definidas no seguinte formato: + +[ async ] in|out [ multi ] tipo stream nome [ , nome ] ; + +As sequências têm uma direcção definida na referência do módulo, tal como é indicado pelos qualificadores necessários 'in' ou 'out'. O argumento 'tipo' define o tipo dos dados, o qual poderá ser qualquer um dos tipos descritos posteriormente para os atributos (nem todos são suportados de momento). Muitos dos módulos usam o tipo de sequência 'audio', o qual é um nome alternativo para o 'float' (vírgula-flutuante) dado que é o formato interno dos dados usados para o áudio. Podem ser definidas várias sequências do mesmo tipo na mesma definição se usar nomes separados por vírgulas. + +As sequências são síncronas por omissão, o que significa que elas são fluxos contínuos de dados a uma taxa constante, como o áudio PCM. O qualificador 'async' indica que é uma sequência assíncrona, a qual é usada para os fluxos de dados descontínuos. O exemplo mais comum de uma sequência assíncrona são as mensagens do &MIDI;. + +A palavra-chave 'multi', que só é válida para as sequências de entrada, indica que a interface suporta um número variável de entradas. Isto é útil para implementar os dispositivos, como as mesas de mistura, que possam aceitar qualquer número de sequências de entrada. + + + + +Atributos + +Os atributos são os dados associados com uma instância de uma interface. Estes são declarados como as variáveis-membro do C++, e podem usar qualquer um dos tipos primitivos 'boolean', 'byte', 'long', 'string', ou 'float'. Você também poderá usar os tipos 'struct' ou 'enum' definidos pelo utilizador, assim como as sequências de tamanho variável, usando a sintaxe sequence<tipo>. Os atributos podem ser marcados opcionalmente como 'readonly' (apenas para leitura). + + + + +Métodos + +Tal como no C++, os métodos podem ser definidos nas interfaces. Os parâmetros dos métodos estão restringidos aos mesmos tipos dos atributos. A palavra-chave 'oneway' indica um método que devolve valores imediatamente e é executado assincronamente. + + + + + +Interfaces-Padrão + +Já estão definidas várias interfaces-padrão de módulos para você no &arts;, como o StereoEffect e o SimpleSoundServer. + + + + +Exemplo + +Um exemplo simples de um módulo retirado do &arts; é o módulo de atraso constante, o qual se encontra no ficheiro kdemultimedia/arts/modules/artsmodules.idl. A definição da interface está indicada em baixo. + +interface Synth_CDELAY : SynthModule { + attribute float time; + in audio stream invalue; + out audio stream outvalue; +}; + + +Este módulo herda de SynthModule. Essa interface, definida no artsflow.idl, define os métodos-padrão que são implementados em todos os módulos de síntese de música. + +O efeito CDELAY atrasa um canal estéreo pelo tempo indicado em 'time', o qual é um parâmetro de vírgula flutuante. A definição da interface tem um atributo do tipo 'float' para guardar o valor do atraso. Ele define duas sequências de áudio de entra e duas sequências de saída (o que é típico nos efeitos estéreo). Não são necessários mais métodos para além dos que ele já herdou. + + + + + + +Mais Acerca das Sequências + +Esta secção cobre alguns tópicos adicionais relacionados com as sequências. + + +Tipos de Sequências + +Existem vários requisitos para a forma como um módulo pode fazer a transmissão. Para ilustrar isto, considere estes exemplos: + + + +Aumentar o sinal por um factor de 2. + + + +Efectuar uma conversão na frequência da amostra. + + + +Descomprimir um sinal codificado em RLE. + + + +Ler os eventos de &MIDI; do /dev/midi00 e introduzi-los numa sequência. + + + +O primeiro caso é o mais simples: depois de receber 200 amostras da entrada, o módulo produz 200 amostras de resultado. Só produz resultados à saída quando obtiver algo à entrada. + +O segundo caso produz números diferentes de amostras de resultado, quando são dadas 200 amostras de entrada. Isto depende de qual a conversão que é efectuada, mas o número é conhecido antecipadamente. + +O terceiro caso é ainda pior. Para o resultado, você nem sequer consegue adivinhar quantos dados as 200 amostras de entrada irão gerar (provavelmente muito mais do que 200 amostras à saída, mas...). + +O último caso é um módulo que se torna ele próprio activo e, de vez em quando, produz dados. + +No &arts;s-0.3.4, só as sequências do primeiro tipo eram tratadas, e a maioria das coisas funcionavam. Isto é provavelmente o que você necessita para criar os módulos que processem áudio. O problema com os outros tipos mais complexos de transmissão é que eles são difíceis de programar e que você não precisa das suas funcionalidades na maior parte das vezes. É por isso que o processamento pode ser feito com dois tipos diferentes de sequências: síncronas e assíncronas. + +As sequências síncronas têm estas características: + + + +Os módulos deverão ser capazes de calcular dados de qualquer dimensão, desde que sejam fornecidos em quantidade suficiente. + + + +Todas as sequências têm a mesma taxa de amostragem. + + + +A função calculateBlock() será chamada quando existirem dados suficientes disponíveis, e o módulo possa confiar nos ponteiros que referenciam os dados. + + + +Não existe nenhuma alocação e libertação de memória a ser feita. + + + +As sequências assíncronas, por outro lado, têm este comportamento: + + + +Os módulos poderão produzir dados algumas das vezes, ou com uma taxa de amostragem variável, ou apenas se eles tiverem dados de entrada de algum descritor de ficheiro. Eles não estão limitados pela regra deve ser capaz de atender pedidos de qualquer tamanho. + + + +As sequências assíncronas de um módulo poderão ter taxas de amostragem totalmente diferentes. + + + +Sequências de saída: existem funções explícitas para alocar pacotes, para enviá-los - e um mecanismo de pesquisa ('polling') opcional que lhe dirá quando deverá criar mais dados. + + + +Sequências de entrada: você obtém uma chamada sempre que recebe um novo pacote - você terá de dizer quando estiver a processar todos os dados desse pacote, o que não deverá acontecer de uma vez (você poderá dizer isso mais tarde e, se toda a gente já processou o pacote, este será libertado/reutilizado). + + + +Quando você declara as sequências, você poderá usar a palavra-chave async para indicar que quer criar uma sequência assíncrona. Por isso, por exemplo, assuma que quer converter uma sequência assíncrona de 'bytes' para uma sequência síncrona de amostras. A sua interface poderia ser algo semelhante a isto: + +interface SequenciaBytesParaAudio : SynthModule { + async in byte stream entrada; // a sequência assíncrona de amostras de entrada + + out audio stream esquerda,direita; // a sequência síncrona de amostras de saída +}; + + + + + +Usar as Sequências Assíncronas + +Imagine que decidiu criar um módulo para produzir som assincronamente. A sua interface seria algo parecido com o seguinte: + +interface UmModulo : SynthModule +{ + async out byte stream saida; +}; + + +Como é que você envia os dados? O primeiro método é chamado de push delivery (tradução livre: 'entrega por empurrão'). Com as sequências assíncronas, você envia os dados como pacotes. Isto significa que você envia pacotes individuais com 'bytes', como no exemplo acima. O processo actual é: alocar um pacote, preenchê-lo, enviá-lo. + +Aqui está isso, em termos de código. Primeiro, é alocado um pacote: + +DataPacket<mcopbyte> *pacote = saida.allocPacket(100); + + +Aí, será preenchido: + +// converter de modo a que o 'fgets' fique contente com um ponteiro (char *) +char *dados = (char *)pacote->contents; + +// como pode ver, você pode encolher o tamanho do pacote depois da alocação, +// se quiser +if(fgets(dados,100,stdin)) + pacote->size = strlen(dados); +else + pacote->size = 0; + + +Agora, o mesmo é enviado: + +pacote->send(); + + +Isto é muito simples, mas se precisar de enviar os pacotes à mesma rapidez com que o destinatário os consegue processar, é necessária outra aproximação, a pull delivery ('entrega por puxão'). Você pede para enviar os pacotes tão rapidamente quanto o destinatário está pronto para processar. Você começa com uma determinada quantidade de pacotes que envia. À medida que o destinatário vai processando um pacote a seguir ao outro, você começa a preenchê-los de novo com dados novos, enviando-os mais uma vez. + +Você inicia isso ao chamar o 'setPull'. Por exemplo: + +saida.setPull(8, 1024); + + +Isto significa que você deseja enviar os pacotes pela 'saida'. Você irá querer começar a enviar 8 pacotes de cada vez e, à medida que o destinatário processar alguns deles, você poderá querer preenchê-los de novo. + +Aí, você precisa de implementar um método que preenche os pacotes, e que poderá se assemelhar ao seguinte: + +void request_saida(DataPacket<mcopbyte> *pacote) +{ + pacote->size = 1024; // não deverá ser maior que 1024 + for(int i = 0;i < 1024; i++) + pacote->contents[i] = (mcopbyte)'A'; + pacote->send(); +} + + +É tudo; quando não tiver mais dados, você poderá começar a enviar pacotes com tamanho nulo, o que irá parar a recepção. + +Repare que é essencial dar ao método o nome exacto request_nome-sequência. + +Foi então discutido o envio dos dados. A recepção dos mesmos é muito mais simples. Suponha que você tem um filtro ParaMinusculas, que simplesmente converte todas as letras para minúsculas: + +interface ParaMinusculas { + async in byte stream entrada; + async out byte stream saida; +}; + + +Isto é mesmo simples de implementar; aqui está a implementação completa: + +class ParaMinusculas_impl : public ParaMinusculas_skel { +public: + void process_entrada(DataPacket<mcopbyte> *pacote_entrada) + { + DataPacket<mcopbyte> *pacote_saida = saida.allocPacket(pacote_entrada->size); + + // convert to lowercase letters + char *texto_entrada = (char *)pacote_entrada->contents; + char *texto_saida = (char *)pacote_entrada->contents; + + for(int i=0;i<pacote_entrada->size;i++) + texto_saida[i] = tolower(texto_entrada[i]); + + pacote_entrada->processed(); + pacote_saida->send(); + } +}; + +REGISTER_IMPLEMENTATION(ParaMinusculas_impl); + + +Mais uma vez, é importante dar o nome process_nome-sequencia ao método. + +Como pode ver, para cada pacote que chega, você obtém uma chamada a uma função ( a process_entrada no caso em questão). Você precisa de chamar o método processed() de um pacote para indicar que acabou de o processar. + +Aqui está uma sugestão de implementação: se o processamento levar mais tempo (&ie; se precisar de esperar pelo resultado da placa de som ou algo do género), não invoque o 'processed' logo, mas armazene o pacote de dados em si e invoque o 'processed' apenas quando você processar de facto esse pacote. Desta forma, os emissores têm uma hipótese de saber quanto tempo leva mesmo a efectuar o seu trabalho. + +Dado que a sincronização não é tão boa com as sequências assíncronas, você deverá usar as sequências síncronas sempre que possível e as assíncronas, só quando for necessário. + + + + +Sequências por Omissão + +Imagine que tem 2 objectos, como por exemplo um ProdutorAudio e um ConsumidorAudio. O ProdutorAudio tem uma sequência de saída e o ConsumidorAudio tem uma de entrada. De cada vez que os tentar ligar, você irá usar estas duas sequências. A primeira utilização da predefinição é permitir-lhe fazer a ligação sem indicar os portos nesse caso. + +Agora imagine que os dois objectos poderão lidar com o estéreo, e cada um possa ter um porto left (esquerdo) e right (direito). Você gostaria à mesma de os ligar de forma tão simples como anteriormente. Mas como é que o sistema de ligações saberia que porto de saída deveria ligar a que porto de entrada? Não tem nenhuma forma de mapear correctamente as sequências. A utilização de portos predefinidos poderá então ser adoptada para indicar várias sequências, com uma dada ordem. Desta forma, quando você ligar um objecto com 2 portos predefinidos a outro objecto com 2 portos predefinidos de entrada, não terá de indicar os portos e, nesse caso, o mapeamento será feito correctamente. + +Obviamente, isto não está limitado ao estéreo. Pode-se tornar qualquer número de sequências como predefinidas se necessário, e a função 'connect' irá verificar se o número de predefinições para os dois objectos correspondem (na direcção necessária), se você não indicar os portos a usar. + +A sintaxe é a seguinte: na &IDL;, você poderá usar a palavra-chave 'default' na declaração da sequência ou numa única linha. Por exemplo: + +interface MisturaDoisEmUm { + default in audio stream entrada1, entrada2; + out audio stream saida; +}; + + +Neste exemplo, o objecto irá esperar que os seus dois portos de entrada estejam ligados por omissão. A ordem é a indicada na linha 'default', por isso, um objecto do tipo: + +interface GeradorRuidoDuplo { + out audio stream bzzt, cuic; + default cuic, bzzt; +}; + + +Fará as ligações do cuic à entrada1 e do bzzt à entrada2 automaticamente. Repare que, dado que só há uma saída para o misturador, será tornada predefinida nesse caso (ver em baixo). A sintaxe usada no gerador de ruído é útil para declarar uma ordem diferente da declaração, ou seleccionando apenas alguns portos como predefinidos. As direcções dos portos nesta linha serão pesquisados pelo &mcopidl;, por isso não os indique. Você até poderá misturar os portos de entrada e de saída numa linha destas, onde só a ordem é que é relevante. + +Existem algumas regras que são seguidas ao usar a herança: + + + +Se for indicada uma lista 'default' na &IDL;, então use-a. Os portos-pai podem ser colocados também nesta lista, quer fossem predefinidos no 'pai' ou não. + + + +Caso contrário, herde as predefinições do 'pai'. A ordem é do tipo 'pai1 predefinicao1, pai1 predefinicao2..., pai2 predefinicao1... Se existir um ascendente comum em dois ramos-pai, é feita uma junção do tipo virtual public na primeira ocorrência da predefinição na lista. + + + +Se não existir à mesma nenhuma predefinição e existir uma sequência simples numa dada direcção, use-a como predefinida nessa direcção. + + + + + + + +Notificações de mudança dos atributos + + + +As notificações de alteração de atributos são uma forma de saber quando é que um atributo foi alterado. Eles são ligeiramente compatíveis com os 'signals' e 'slots' do &Qt; e do Gtk. Por exemplo, se você tiver um elemento gráfico, como uma barra deslizante, que configura um número entre 0 e 100, você poderá ter normalmente um objecto que faça algo com esse número (por exemplo, poderá controlar o volume de um sinal de áudio). Por isso, você gostaria que, de cada vez que movesse a barra, o objecto que ajustasse o volume fosse notificado. Uma ligação entre um emissor e um receptor. + +O &MCOP; lida com isso, sendo capaz de oferecer notificações de cada vez que os atributos são alterados. Tudo o que for declarado como atributo na &IDL;, pode emitir essas notificações de alterações, e devê-lo-á fazer, sempre que for modificado. Tudo o que for declarado como atributo poderá também receber essas notificações de alteração. Por isso, se por exemplo tiver duas interfaces de &IDL;, como as seguintes: + +interface BarraDeslizante { + attribute long min,max; + attribute long posicao; + }; + interface ControloVolume : Arts::StereoEffect { + attribute long volume; // 0..100 + }; + + +Você podê-las-á ligar com as notificações de alteração. Isto funciona usando a operação normal de 'connect' do sistema de fluxo. Neste caso, o código de C++ para ligar dois objectos deverá ser semelhante ao seguinte: + +#include <connect.h> +using namespace Arts; +[...] +connect(barra,"posicao_changed",controlo_Volume,"volume"); + + +Como pode ver, cada atributo oferece duas sequências diferentes, uma para enviar as notificações de alteração, chamada de nome-atributo_changed, e outra para receber as notificações de alteração, chamada nome-atributo. + +É importante saber que as notificações de alteração e as sequências assíncronas são compatíveis. São também transparentes na rede. Por isso, você consegue ligar uma notificação de alteração de um atributo 'float' de um elemento &GUI; a uma sequência assíncrona de um módulo de síntese a correr noutro computador. Isto, obviamente, implica que as notificações de alteração não sejam síncronas, o que significa que, depois de ter enviado a notificação de alteração, poderá levar algum tempo até que esta seja de facto recebida. + + + +Enviar as notificações de alterações + +Ao implementar objectos que tenham atributos, você precisa de enviar as notificações de alteração sempre que um dado atributo muda. O código para o fazer é semelhante ao seguinte: + +void KPoti_impl::valor(float novoValor) + { + if(novoValor != _valor) + { + _valor = novoValor; + valor_changed(novoValor); // <- envia a notificação de alteração + } + } + + +É bastante recomendado que use código deste género para todos os objectos que implementar, de modo a que as notificações de alterações possam ser usadas pelas outras pessoas. Você deverá, contudo, evitar o envio das notificações com demasiada frequências, por isso, se estiver a fazer processamento de sinal, é provavelmente melhor que você mantenha um registo de quando enviou a sua última notificação, para que não envie uma com cada uma das amostras que processar. + + + + +Aplicações para as notificações de alteração + +Será especialmente útil usar as notificações de alteração em conjunto com os osciloscópios (as coisas que visualizam os dados de áudio, por exemplo), os elementos gráficos, elementos de controlo e na monitorização. O código que usa isto está em kdelibs/arts/tests e na implementação experimental do 'artsgui', que poderá encontrar em kdemultimedia/arts/gui. + + + + + + + + + + +O ficheiro <literal role="extension" +>.mcoprc</literal +> + +O ficheiro .mcoprc (na pasta pessoal de cada utilizador) poderá ser usado para configurar o &MCOP; em alguns aspectos. De momento, é possível o seguinte: + + + + +GlobalComm + +O nome de uma interface a usar para a comunicação global. A comunicação global é usada para procurar os outros objectos e obter o 'cookie' secreto. Vários clientes/servidores de &MCOP; que deverão ser capazes de falar entre si precisam de ter um objecto 'GlobalComm' que seja capaz de partilhar informações entre eles. De momento, os valores possíveis são o Arts::TmpGlobalComm para comunicar através da pasta /tmp/mcop-utilizador (que irá funcionar apenas no computador local) ou o Arts::X11GlobalComm para comunicar através das propriedades da janela de topo do servidor X11. + + + + +TraderPath + + +Indica onde procurar pela informação do mediador. Você poderá indicar aqui mais do que uma pasta, separando as pastas com vírgulas, como no exemplo + + + + + +ExtensionPath + + +Indica a partir de que pastas é que as extensões (na forma de bibliotecas dinâmicas) são carregadas. Podem ser indicados vários valores, separados por vírgulas. + + + + + +Um exemplo que usa tudo isso é o seguinte: + +# Ficheiro $HOME/.mcoprc +GlobalComm=Arts::X11GlobalComm + +# se você é um programador, será útil adicionar uma pasta na sua área +# para que a localização do(a) mediador/extensão sejam capazes de adicionar +# componentes sem os instalar +TraderPath="/opt/kde2/lib/mcop","/home/ze/mcop_desenvolvimento/mcop" +ExtensionPath="/opt/kde2/lib","/home/ze/mcop_desenvolvimento/lib" + + + + + +O &MCOP; para os Utilizadores de <acronym +>CORBA</acronym +> + +Se já usou o CORBA antes, irá concluir que o &MCOP; é muito parecido, de facto. De facto, o &arts;, antes da versão 0.4 usava o CORBA. + +A ideia básica do CORBA é a mesma: você implementa os objectos (componentes). Se usar as funcionalidades do &MCOP;, os seus objectos não estão só disponíveis como classes normais do mesmo processo (através das técnicas normais do C++) - eles passam a estar disponíveis de forma transparente para os servidores remotos. Para isto funcionar, a primeira coisa que precisa de fazer é indicar a interface dos seus objectos num ficheiro &IDL; - tal como na &IDL; do CORBA. Existem apenas algumas diferenças. + + +Funcionalidades do <acronym +>CORBA</acronym +> que Faltam no &MCOP; + +No &MCOP; não existem parâmetros in e out nas invocações dos métodos. Os parâmetros são sempre de entrada e o código devolvido é sempre de saída, o que significa que a interface: + +// idl de CORBA +interface Conta { + void depositar( in long quantia ); + void levantar( in long quantia ); + long saldo(); +}; + + +é escrito como + +// idl de MCOP +interface Conta { + void depositar( long quantia ); + void levantar( long quantia ); + long saldo(); +}; + + +no &MCOP;. + +Não existe o suporte de excepções. O &MCOP; não tem excepções - ele usa algo de diferente para o tratamento de erros. + +Não existem tipos 'union' nem 'typedef's. Não se sabe se é uma falha de facto, algo que uma pessoa necessitasse desesperadamente para sobreviver. + +Não existe suporte para passar referências a interfaces ou objectos + + + + +Funcionalidades do <acronym +>CORBA</acronym +> que São Diferentes no &MCOP; + +Você declara as sequências como sequencetipo no &MCOP;. Não existe necessidade de um 'typedef'. Por exemplo, em vez de: + +// CORBA idl +struct Linha { + long x1,y1,x2,y2; +}; +typedef sequence<Linha> Linhas; +interface Desenhador { + void desenhar(in Linhas linhas); +}; + + +você iria descrever + +// IDL de MCOP +struct Linha { + long x1,y1,x2,y2; +}; +interface Desenhador { + void desenhar(sequence<Linha> linhas); +}; + + + + + +Funcionalidades do &MCOP; Que Não Estão no <acronym +>CORBA</acronym +> + +Você pode declarar as sequências que serão então avaliadas pela plataforma do &arts;. As sequências são declaradas de forma semelhante aos atributos. Por exemplo: + +// MCOP idl +interface Synth_ADICIONAR : SynthModule { + in audio stream sinal1,sinal2; + out audio stream saida; +}; + + +Isto diz que o seu objecto irá aceitar duas sequências síncronas de áudio chamadas 'sinal1' e 'sinal2'. Por síncronas significa que são sequências que distribuem 'x' amostras por segundo (ou por outro período), de modo a que o escalonador garanta que lhe fornecerá uma quantidade balanceada de dados de entrada (⪚ existem 200 amostras de 'sinal1' para 200 amostras de 'sinal2'). Você garante que, se o seu objectivo for chamado com essas 200 amostras de 'sinal1' e 'sinal2', será capaz de produzir exactamente 200 amostras de 'saida'. + + + + +A Interface para a Linguagem C++ do &MCOP; + +Isto difere do CORBA principalmente: + + + +As cadeias de caracteres usam a classe de C++ do STL string. Quando é armazenado nas sequências, elas são armazenadas tal-e-qual, o que significa que são consideradas como sendo um tipo primitivo. Deste modo, elas precisam de ser copiadas. + + + +os 'long's são 'long's normais (contando que são de 32 bits). + + + +As sequências usam a classe de C++ do STL vector. + + + +As estruturas são todas derivadas da classe do &MCOP; Type, e são geradas no compilador de &IDL; do &MCOP;. Quando forem armazenadas em sequências, elas não serão guardadas tal-e-qual , mas sim como referências porque, caso contrário, iriam ocorrer várias cópias. + + + + + +Implementar os Objectos do &MCOP; + +Depois de passar as interfaces pelo compilador de &IDL;, você precisa de derivar da classe _skel. Por exemplo, assuma que definiu a sua interface da seguinte forma: + +// IDL do MCOP: ola.idl +interface Ola { + void Ola(string s); + string concatenar(string s1, string s2); + long somar2(long a, long b); +}; + + +Você pode passar isso pelo compilador de &IDL;, invocando o comando mcopidl ola.idl, o que por sua vez irá gerar o ola.cc e o ola.h. Para o implementar, você precisa de definir uma classe de C++ que herde do esqueleto: + +// ficheiro de inclusão de C++ - inclua o ola.h algures +class Ola_impl : virtual public Ola_skel { +public: + void ola(const string& s); + string concatenar(const string& s1, const string& s2); + long somar2(long a, long b); +}; + + +Finalmente, você terá de implementar os métodos como C++ normal + +// ficheiro de implementação de C++ + +// como pode ver, as 'string's são passadas como referências de 'const string' +void Ola_impl::ola(const string& s) +{ + printf("Ola '%s'!\n",s.c_str()); +} + +// quando têm um valor a devolver são passadas como cadeias de caracteres normais +string Ola_impl::concatenar(const string& s1, const string& s2) +{ + return s1+s2; +} + +long Ola_impl::somar2(long a, long b) +{ + return a+b; +} + + +Logo que faça isso, você terá um objecto que poderá comunicar usando o &MCOP;. Basta criar um (usando as funcionalidades normais do C++ para criar um objecto): + +Servidor do Ola_impl; + + +E assim que dê a alguém a referência + +string referencia = servidor._toString(); + printf("%s\n",referencia.c_str()); + + +e ir à ciclo de inactividade do &MCOP; + +Dispatcher::the()->run(); + + +As pessoas podem aceder à coisa usando + +// este código poderá correr em qualquer lado - não necessariamente no mesmo +// processo (poderá também correr num computador/arquitectura diferentes) + + Ola *h = Ola::_fromString([a referência do objecto impressa acima]); + + +e invocar os métodos: + +if(h) + h->ola("teste"); + else + printf("O acesso falhou?\n"); + + + + + + +Considerações de Segurança do &MCOP; + +Dado que os servidores de &MCOP; irão atender os pedidos num porto de TCP, potencialmente toda a gente (se você estiver na Internet) poderá tentar ligar-se aos serviços do &MCOP;. Por isso, é importante autenticar os clientes. O &MCOP; usa o protocolo 'md5-auth'. + +O protocolo 'md5-auth' faz o seguinte para garantir que só os clientes seleccionados (de confiança) se poderão ligar a um servidor: + + + +Ele assume que você dá a todos os clientes um 'cookie' secreto. + + + +De cada vez que um cliente se liga, ele verifica se o cliente conhece esse 'cookie' secreto, sem o transferir de facto (nem sequer de forma a que alguém que esteja a escutar o tráfego de rede o possa descobrir). + + + + +Para dar a cada cliente esse 'cookie' secreto, o &MCOP; irá (normalmente) colocá-lo na pasta mcop (em /tmp/mcop-USER/secret-cookie). Claro, você podê-lo-á copiar para outros computadores. Contudo, se o fizer, use um mecanismo de transferência seguro, como o scp (do ssh). + +A autenticação dos clientes usa os seguintes passos: + + + +[SERVIDOR] gera um 'cookie' novo (aleatório) R + + + +[SERVIDOR] envia-o para o cliente + + + +[CLIENTE] lê o "cookie secreto" S de um ficheiro + + + +[CLIENTE] baralha os 'cookies' R e S para um 'cookie' baralhado M usando o algoritmo MD5 + + + +[CLIENTE] envia o M para o servidor + + + +[SERVIDOR] verifica que, ao baralhar o R e o S dará o mesmo resultado que o 'cookie' M recebido do cliente. Em caso afirmativo, a autenticação foi bem-sucedida. + + + + +Este algoritmo deverá ser seguro, atendendo a que + + + +Os 'cookies' secretos e os aleatórios são aleatórios quanto baste e + + + +O algoritmo de dispersão do MD5 não permite descobrir o texto original, que é o 'cookie' secreto S e o 'cookie' aleatório R (o qual é conhecido, de qualquer forma), a partir do 'cookie' baralhado M. + + + +O protocolo &MCOP; irá começar todas as ligações novas com um processo de autenticação. Basicamente, assemelha-se ao seguinte: + + + + +O servidor envia uma mensagem ServerHello que descreve os protocolos de autenticação conhecidos. + + + +O cliente envia uma mensagem ClientHello que inclui a informação de autenticação. + + + +O servidor envia uma mensagem AuthAccept. + + + +Para verificar se a segurança funciona de facto, deverá ver como é que as mensagens se processam nas ligações não-autenticadas: + + + +Antes de a autenticação ser bem sucedida, o servidor não irá receber outras mensagens da ligação. Em vez disso, se o servidor por exemplo estiver à espera de uma mensagem ClientHello e obtiver uma mensagem de 'mcopInvocation', irá quebrar a ligação. + + + +Se o cliente não enviar uma mensagem de &MCOP; válida de todo (sem o código especial do &MCOP; no cabeçalho da mensagem) na fase de autenticação, mas sim outra coisa qualquer, a ligação é quebrada. + + + +Se o cliente tentar enviar uma mensagem mesmo muito grande (> 4096 bytes na fase de autenticação, o tamanho da mensagem é truncado para 0 bytes, o que fará com que não seja aceite para a autenticação). Isto é para evitar que os clientes não-autenticados enviem mensagens de ⪚ 100 megabytes, o que faria com que fosse recebida e com que o servidor estoirasse com falta de memória. + + + +Se o cliente enviar uma mensagem ClientHello corrompida (uma, onde a descodificação falhe), a ligação é mais uma vez quebrada. + + + +Se o cliente não enviar nada de nada, então ocorrerá a expiração de um tempo-limite (ainda por implementar). + + + + + + +Especificação do Protocolo &MCOP; + + +Introdução + +Tem semelhanças conceptuais ao CORBA, mas pretende extendê-lo de todas as formas necessárias para as operações multimédia em tempo-real. + +Oferece um modelo de objectos multimédia, o qual poderá ser usado para: a comunicação entre os componentes num espaço de endereçamento (um processo) e entre componentes que existam em tarefas, processos ou mesmo máquinas diferentes. + +Tudo junto, será desenhado para uma performance extremamente alta (de modo a que tudo seja optimizado para ser extremamente rápido), o que é adequado para as aplicações multimédia bastante comunicativas. Por exemplo, a transmissão de vídeos é uma das aplicações do &MCOP;, onde a maioria das implementações de CORBA 'cairiam de joelhos'. + +As definições das interfaces conseguem lidar com as seguintes coisas nativamente: + + + +Sequências contínuas de dados (como os dados de áudio). + + + +Sequências de dados de eventos (como os eventos do &MIDI;). + + + +Contagem de referências real. + + + +e os truques mais importantes do CORBA, como + + + +As invocações síncronas de métodos. + + + +As invocações de métodos assíncronas. + + + +A construção de tipos de dados definidos pelo utilizador. + + + +Herança múltipla. + + + +A passagem de referências de objectos. + + + + + + +A Codificação das Mensagens do &MCOP; + +Objectivos/ideias de desenho: + + + + +A codificação deverá ser simples de implementar. + + + +A descodificação necessita que o destinatário saiba qual é o tipo que ele deseja descodificar. + + + +O destinatário está à espera de usar toda a informação - por isso, só são ignorados os dados no protocolo ao nível em que: + + + +Se você souber que vai receber um bloco de 'bytes', não precisa de olhar para cada 'byte', à procura de um marcador de fim. + + + +Se você souber que vai receber uma cadeia de caracteres, não precisa de a ler até encontrar o 'byte' zero para descobrir o seu tamanho, contudo, + + + +Se você souber que vai receber uma sequência de cadeias de caracteres, você precisa de saber o tamanho de cada uma delas para descobrir o fim da sequência, dado que as cadeias de caracteres têm tamanho variável. Mas se você usar as cadeias de caracteres para algo útil, você terá de o fazer à mesma, por isso não se perde nada. + + + + + + +O mínimo de sobrecarga possível. + + + + + +A codificação dos diferentes tipos é mostrada na tabela em baixo: + + + + + +Tipo +Processo de Codificação +Resultado + + + + + +void +Os tipos void são codificados, omitindo-os, de modo a que e não seja nada escrito no canal. + + + + +long +é codificado como 4 'bytes', em que o 'byte' mais significativo vem primeiro, de modo a que o número 10001025 (correspondente a 0x989a81) será codificado como: +0x00 0x98 0x9a 0x81 + + + +enums +são codificados como longs + + + + +byte +é codificado como um único 'byte', de modo a que o 'byte' 0x42 será codificado como: +0x42 + + + +string +é codificado como um long, contendo o tamanho da cadeia de caracteres seguinte, e pela sequência de caracteres propriamente dita, terminando com um 'byte' a zeros (que está incluído na contagem do tamanho). + +inclui o 'byte' 0 final na contagem do tamanho! + +O ola seria codificado da seguinte forma: +0x00 0x00 0x00 0x04 0x6f 0x6c 0x60 0x00 + + + +boolean +é codificado como um 'byte', contendo 0 se for false (falso) ou 1 se for true (verdadeiro), de modo a que o valor booleano true é codificado como: +0x01 + + + +float +é codificado na representação de 4 'bytes' do IEEE754 - a documentação detalhada de como o IEEE funciona estão aqui: http://twister.ou.edu/workshop.docs/common-tools/numerical_comp_guide/ncg_math.doc.html e aqui: http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html. Deste modo, o valor 2,15 seria codificado como: +0x9a 0x99 0x09 0x40 + + + +'struct' +Uma estrutura é codificada com base no seu conteúdo. Não existem prefixos ou sufixos adicionais, por isso a estrutura +struct teste { + string nome; // que é igual a "ola" + long valor; // que é igual a 10001025 (0x989a81) +}; + +seria codificada como + +0x00 0x00 0x00 0x04 0x6f 0x6c 0x60 0x00 +0x00 0x98 0x9a 0x81 + + + + +sequência +uma sequência é codificada através da listagem do número de elementos que se seguem e da descodificação dos elementos, um a um. +Por isso uma sequência de 3 'longs' 'a', with a[0] = 0x12345678, a[1] = 0x01 e a[2] = 0x42 seria codificada como: + +0x00 0x00 0x00 0x03 0x12 0x34 0x56 0x78 +0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x42 + + + + + + + +Se você precisar de fazer referência a um tipo, todos os tipos primitivos são referidos pelos nomes indicados acima. As estruturas e os enumerados têm nomes próprios (como Header). As sequências são referidas como um *tipo normal, de modo que uma sequência de 'longs' é um *long e uma sequência de estruturas Header é um *Header. + + + + +Mensagens + +O formato do cabeçalho das mensagens do &MCOP; está definido pela estrutura seguinte: + +struct Header { + long magic; // o valor 0x4d434f50, que é codificado como MCOP + long messageLength; + long messageType; +}; + + +Os valores possíveis de messageTypes são, de momento + +mcopServerHello = 1 + mcopClientHello = 2 + mcopAuthAccept = 3 + mcopInvocation = 4 + mcopReturn = 5 + mcopOnewayInvocation = 6 + + +Algumas notas acerca das mensagens do &MCOP;: + + + + +Todas as mensagens começam com uma estrutura Header. + + + +Alguns dos tipos de mensagens deverão ser ignorados pelo servidor, enquanto a autenticação não estiver completa. + + + +Depois de receber o cabeçalho, o tratamento do protocolo (ligação) poderá receber a mensagem por completo, sem olhar para o seu conteúdo. + + + +O 'messageLength' no cabeçalho é, obviamente em alguns casos, redundante, o que significa que esta aproximação não é minimalista no que respeita ao número de 'bytes'. + +Contudo, conduz a uma implementação simples (e rápida) do processamento não-bloqueante de mensagens. Com a ajuda do cabeçalho, as mensagens poderão ser recebidas pelas classes de tratamento do protocolo em segundo plano (não-bloqueante), se existirem demasiadas ligações ao servidor, todas elas poderão ser servidas em paralelo. Você não precisa de olhar para o conteúdo da mensagem para a receber (e para determinar que terminou), basta olhar para o cabeçalho, por isso o código para isso é relativamente simples. + +Logo que esteja lá uma mensagem, esta poderá ser descodificada e processada num único passo, sem se preocupar com os casos em que nem todos os dados foram recebidos (porque o 'messageLength' garante que está lá tudo). + + + + +Invocações + +Para invocar um método remoto, você precisa de enviar a seguinte estrutura no corpo de uma mensagem de &MCOP; com o messageType = 1 (mcopInvocation): + +struct Invocation { + long objectID; + long methodID; + long requestID; +}; + + +depois disso, você envia os parâmetros como uma estrutura, ⪚ se você invocar o método 'concatenar(string s1, string s2)', você envia uma estrutura do tipo + +struct InvocationBody { + string s1; + string s2; +}; + + + +se o método foi declarado como 'só de ida0 - o que significa que é assíncrono sem código devolvido - então é tudo. Caso contrário, você iria receber como resposta uma mensagem com o messageType = 2 (mcopReturn) + +struct ReturnCode { + long requestID; + <tipo-a-devolver> result; +}; + + + +em que o <tipo-a-devolver> é o tipo do resultado. Como os tipos 'void' são omitidos na codificação, você também poderá só escrever o 'requestID' se regressar de um método 'void'. + +Por isso o nosso método 'string concatenar(string s1, string s2)' iria originar um código de resultado do tipo + +struct ReturnCode { + long requestID; + string result; +}; + + + + + +Inspeccionar as Interfaces + +Para fazer as invocações, você teria de conhecer os métodos que um objecto suporta. Para o fazer, o 'methodID' 0, 1, 2 e 3 estão pré-destinados a certas funcionalidades. Isto é + +long _lookupMethod(MethodDef defMetodo); // methodID sempre a 0 +string _interfaceName(); // methodID sempre a 1 +InterfaceDef _queryInterface(string nome); // methodID sempre a 2 +TypeDef _queryType(string nome); // methodID sempre a 3 + + +para ler isso, você obviamente precisa de + +struct MethodDef { + string methodName; + string type; + long flags; // posto a 0 por agora (será necessário na transmissão) + sequence<ParamDef> signature; +}; + +struct ParamDef { + string name; + long typeCode; +}; + + +o campo 'parameters' contém os componentes do tipo que indicam os tipos dos parâmetros. O tipo do valor devolvido é indicado no campo 'type' do MethodDef. + +De forma restrita, só os métodos _lookupMethod() e _interfaceName() são diferentes de objecto para objecto, enquanto que o _queryInterface() e o _queryType() são sempre os mesmos. + +O que são esses methodIDs? Se você fizer uma invocação de &MCOP;, irá ficar à espera de passar um número para o método que você está a invocar. A razão para tal é que os números podem ser processados muito mais depressa do que as cadeias de caracteres ao executar um pedido de &MCOP;. + +Por isso, como é que obtém esses números? Se você souber a assinatura do método, existe um MethodDef que descreve o método (e que contém o nome, o tipo, os nomes e os tipos de parâmetros, entre outras coisas) e você poderá passar isso ao '_lookupMethod' do objecto onde deseja invocar um método. Dado que o '_lookupMethod' está pré-associado ao 'methodID' 0, você não deverá ter problemas ao fazê-lo. + +Por outro lado, se você não souber a assinatura do método, você poderá descobrir os métodos que são suportados, usando o '_interfaceName', o '_queryInterface' e o '_queryType'. + + + +Definições dos Tipos + +Os tipos de dados definidos pelo utilizador são descritos com a estrutura TypeDef: + +struct TypeComponent { + string type; + string name; +}; + +struct TypeDef { + string name; + + sequence<TypeComponent> contents; +}; + + + + + + +Porque é que o &arts; Não Usa o &DCOP; + +Dado que o &kde; largou o CORBA por completo e está a usar o &DCOP; em todo o lado, naturalmente a questão levantar-se-á: 'porque é que o &arts; não o faz também?'. No fim de tudo, o suporte do &DCOP; está no KApplication, é bem-mantido, supostamente integra-se bem com a libICE, entre outras coisas. + +Dado que existirá (potencialmente) uma grande quantidade de pessoas a perguntar se ter o &MCOP; para além do &DCOP; é realmente necessário, aqui está a resposta. Não levem o autor a mal, porque não está a dizer o &DCOP; é mau. Simplesmente quer dizer o &DCOP; não é a solução adequada para o &arts; (embora seja uma boa solução para outras coisas). + +Primeiro, você precisa de compreender para que é que o &DCOP; foi criado. Desenvolvido em dois dias durante o encontro &kde;-TWO, pretendia ser o mais simples possível, um protocolo de comunicações realmente leve. Especialmente, a implementação descartou tudo o que pudesse envolver complexidade, como por exemplo um conceito completo de como os tipos de dados seriam codificados. + +Ainda que o &DCOP; não se preocupe com certas coisas (por exemplo: como é que se envia uma cadeia de caracteres de forma transparente na rede?) - isso precisa de ser feito. Por isso, tudo o que o &DCOP; não faz, fica a cargo do &Qt; nas aplicações do &kde; que usam o &DCOP; hoje em dia. Isto é em grande parte gestão de tipos (usando o operador de serialização do &Qt;). + +Por isso, o &DCOP; é um protocolo mínimo que permite perfeitamente às aplicações do &kde; enviarem mensagens simples do tipo abrir uma janela a apontar para http://www.kde.org ou os seus dados de configuração mudaram. Contudo, dentro do &arts; o foco situa-se noutras coisas. + +A ideia é que alguns pequenos 'plugins' do &arts; irão comunicar, trocando algumas estruturas de dados como eventos MIDI e ponteiros de posição na música ou grafos de fluxo. + +Estes são tipos de dados complexos, os quais deverão ser enviados entre objectos diferentes e passados como sequências ou parâmetros. O &MCOP; fornece um conceito de tipos para definir dados complexos a partir de dados mais simples (de forma semelhante às estruturas ou vectores no C++). O &DCOP; não se preocupa com os tipos de todo, por isso este problema seria deixado para o programador - como: criar classes de C++ para os tipos, certificando-se que eles pudessem serializar-se correctamente (por exemplo: suportar o operador de transmissão do &Qt;). + +Mas desta forma, eles seriam inacessíveis a tudo o que não fosse codificação directa de C++. Especificamente, você não poderia desenhar uma linguagem de 'scripting' que conhecesse todos os 'plugins' de tipo que poderão estar expostos, dado que eles não se descrevem a si próprios. + +O mesmo argumento se aplica também às interfaces. Os objectos do &DCOP; não expõem as suas relações, hierarquias de herança, etc. - se você fosse criar um navegador de objectos que lhe mostrasse que atributos tem tido este objecto, seria mal-sucedido. + + +Embora o Matthias tenha dito que existe uma função especial functions em cada objecto que lhe indica os métodos que um dado objecto suporta, isto deixa de fora coisas como os atributos (propriedades), as sequências e as relações de herança. + +Isto quebra seriamente as aplicações como o &arts-builder;. Mas lembre-se. o &DCOP; não pretendia ser um modelo de objectos (dado que o &Qt; já tem um com o moc e semelhantes), nem pretende ser algo semelhante ao CORBA, mas simplesmente uma forma de fornecer comunicação entre aplicações. + +Porque ainda o &MCOP; existe é: deverá funcionar perfeitamente com canais entre objectos. O &arts; faz um uso intensivo de pequenos 'plugins', que se interligam entre si com as sequências. A versão em CORBA do &arts; tinha de introduzir uma divisão muito incómoda entre os objectos SynthModule, os quais eram os módulos de trabalho internos que faziam a transmissão e a interface CORBA, que era algo externo. + +Muito do código preocupava-se em fazer a interacção entre os objectos SynthModule e a interface CORBA parecer natural, mas não o era, porque o CORBA não sabia nada de nada sobre as sequências. O &MCOP; sabe. Olhe para o código (algo como o simplesoundserver_impl.cc). Muito melhor! As sequências podem ser declaradas na interface dos módulos e implementadas de forma natural. + +Ninguém o pode negar. Uma das razões pela qual o &MCOP; foi feito foi a velocidade. Aqui estão alguns argumentos porque é que o &MCOP; será definitivamente mais rápido que o &DCOP; (sem sequer mostrar imagens). + + +Uma invocação do &MCOP; terá um cabeçalho com seis longs. Isto é: + + +o código do MCOP +o tipo da mensagem (invocação) +o tamanho do pedido em 'bytes' +ID do pedido +ID do objecto de destino +ID do método de destino + + +Depois disso, seguem-se os parâmetros. Repare que a descodificação destes é extremamente rápida. Você poderá usar pesquisas em tabelas para encontrar o objecto e a função de descodificação do método, o que significa que a complexidade é O(1) (levará a mesma quantidade de tempo, independentemente de quantos objectos estão vivos, ou de quantas funções existem). + +Comparando isto com o &DCOP;, verá que existem, pelo menos + + +uma cadeia de caracteres para o objecto de destino - algo do tipo aMinhaCalculadora +um texto do tipo adicionarNumero(int,int) para indicar qual o método +muita mais informação do protocolo adicionada pela 'libICE', e outros detalhes do DCOP que o autor desconhece + + +Tudo isto é muito doloroso para descodificar, dado que você irá necessitar de processar o texto, procurar a função, &etc;. + +No &DCOP;, todos os pedidos são passados através de um servidor (o DCOPServer). Isto significa que o processo de uma invocação síncrona se assemelha a: + + + +O processo do cliente envia o pedido. + + + +O DCOPserver (o homem-no-meio) recebe a invocação e procurar onde precisa de ir, enviando para o servidor real. + + + +O processo do servidor recebe a invocação, efectua o pedido e envia o resultado. + + + +O DCOPserver (o homem-no-meio) recebe o resultado e ... envia-o para o cliente. + + + +O cliente descodifica a resposta. + + + +No &MCOP;, a mesma invocação assemelha-se ao seguinte: + + + +O processo do cliente envia o pedido. + + + +O processo do servidor recebe a invocação, efectua o pedido e envia o resultado. + + + +O cliente descodifica a resposta. + + + +Digamos que ambos foram implementados correctamente, a estratégia ponto-a-ponto do &MCOP; deverá ser mais rápida por um factor de 2, do que a estratégia do 'homem-no-meio' do &DCOP;. Repare contudo que existiam razões para escolher a estratégia do &DCOP;, nomeadamente: se você tiver 20 aplicações a correr, se cada uma estiver a falar com outra, você precisa de 20 ligações no &DCOP;, e de 200 com o &MCOP;. Contudo, no caso do multimédia, isto não suposto ser a configuração normal. + +Tentou-se comparar o &MCOP; com o &DCOP;, fazendo uma invocação do tipo 'adicionar dois números'. Alterou-se o 'testdcop' para conseguir isto. Porém, o teste pode não ter sido fidedigno do lado do &DCOP;. Invocou-se o método no mesmo processo que fez a chamada para o &DCOP;, e não se soube como se ver livre de uma mensagem de depuração, pelo que foi feita redireccionamento do resultado. + +O teste só usava um objecto e uma função, esperando que os resultados do &DCOP; começassem a descer com mais objectos e funções, enquanto os resultados do &MCOP; se deveriam manter iguais. Também, o processo do dcopserver não estava ligado a nenhumas outras aplicações, pelo que, se estivessem outras aplicações ligadas, a performance do encaminhamento iria decrescer. + +O resultado obtido foi que, enquanto o &DCOP; obteve cerca de 2000 invocações por segundo, o &MCOP; obteve um pouco mais de 8000 invocações por segundo. Isto resulta num factor de 4. Sabe-se que o &MCOP; não está ajustado para o máximo possível, ainda. (Comparação: o CORBA, implementado no 'mico', faz algo entre 1000 e 1500 invocações por segundo). + +Se você quiser dados mais em bruto, pense em fazer alguma aplicação de medida de performance para o &DCOP; e envie-a para o autor. + +O CORBA tinha a funcionalidade interessante de que você poderia usar os objectos que você implementou uma vez, como processos de servidor separados ou como bibliotecas. Você poderia usar o mesmo código para tal, e o CORBA iria decidir de forma transparente o que fazer. Com o &DCOP;, não é realmente pretendido, e tanto quanto se sabe não é possível realmente. + +O &MCOP;, por outro lado, deverá suportá-lo logo desde o início. Por isso, você poderá correr um efeito dentro do &artsd;. Mas se você for um editor de ondas, você poderá optar por correr o mesmo efeito dentro do espaço do processo. + +Embora o &DCOP; sej, em grande medida, uma forma de comunicar entre as aplicações, o &MCOP; também o é. Especialmente para a transmissão multimédia, o que é importante (dado que você poderá correr vários objectos &MCOP; em paralelo, para resolver uma tarefa de multimédia na sua aplicação). + +Ainda que o o &MCOP; não o faça de momento, as possibilidades estão em aberto para implementar as funcionalidades de qualidade de serviço. Algo do género aquele evento &MIDI; é mesmo MUITO importante, em comparação com esta invocação. Ou algo do tipo necessita de estar ali a tempo. + +Por outro lado, a transferência de sequências poderá ser integrada no protocolo &MCOP; sem problemas e ser combinada com elementos de QoS. Dado que o protocolo poderá ser alterado, a transferência de sequências do &MCOP; não deverá ser mais lenta do que uma transmissão convencional de TCP, mas: é mais fácil e mais consistente de usar. + +Não existe necessidade de basear uma plataforma de multimédia no &Qt;. Ao decidir isso, e usando toda aquela serialização e outras funcionalidades giras do &Qt;, iria conduzir facilmente a que a plataforma se tornasse apenas para o &Qt; ou (para apenas para o &kde;). Quer dizer: assim que se vir que os GNOMEs comecem a usar o &DCOP;, também, ou algo do género, provavelmente o autor ficará errado. + +Enquanto se sabe que o &DCOP; basicamente não sabe nada sobre os tipos de dados que envia, de modo que você poderia usar o &DCOP; sem usar o &Qt;, veja como é que é usado na utilização do dia-a-dia do &kde;: as pessoas enviam tipos como o QString, o QRect, o QPixmap, o QCString, ..., de um lado para o outro. Estes usam a serialização do &Qt;. Por isso, se alguém optar por suportar o &DCOP; num programa do GNOME, ele teria de afirmar que usava os tipos QString,... (ainda que não o faça, de facto) e emular a forma como o &Qt; faz a transmissão, ou então teria de enviar outros tipos de cadeias de caracteres, imagens e rectângulos, o que deixaria de ter possibilidades de interoperabilidade. + +Bem, seja o que for, o &arts; pretendeu sempre funcionar com ou sem o &kde;, com ou sem o &Qt;, com ou sem o X11, e talvez com ou sem o &Linux; (e não há problema nenhum com as pessoas que o transpõem para um sistema operativo proprietário conhecido). + +É a posição do autor que os componentes não&GUI; deverão ser criados de forma independente da &GUI;, para possibilitar a partilha destes pelas quantidades maiores de programadores (e utilizadores) possível. + +É óbvio que o uso de dois protocolos de IPC pode causar problemas. Ainda mais, se ambos não forem normas. Contudo, pelas razões indicadas acima, a mudança para o &DCOP; não é uma opção. Se existir um interesse significativo em encontrar uma forma de unir os dois, ok, poderemos tentar. Até poderemos tentar fazer com que o &MCOP; 'fale' IIOP, onde então poderemos passar a ter um ORB de CORBA. + +Falou-se com o Matthias Ettrich um pouco sobre o futuro dos dois protocolos e encontraram-se montes de formas como as coisas poderão seguir daqui para a frente. Por exemplo, o &MCOP; poderia tratar da comunicação de mensagens no &DCOP;, colocando os protocolos um pouco mais juntos entre si. + +Por isso, algumas soluções possíveis seriam: + + + +Criar uma 'gateway' de &MCOP; - &DCOP; (o qual deverá ser possível, e possibilitaria a interoperabilidade) - nota: existe um protótipo experimentar, se quiser ver algo sobre o assunto. + + + +Integrar tudo o que os utilizadores do &DCOP; esperam no &MCOP;, e tentar apenas usar o &MCOP; - uma pessoa até poderia adicionar uma opção de homem-no-meio no &MCOP;, também ;) + + + +Basear o &DCOP; no &MCOP; em vez da 'libICE', e começar a integrar lentamente as coisas em conjunto. + + + +Contudo, poderá não ser a pior possibilidade para usar cada protocolo em tudo em que se pensou usar (existem algumas grandes diferenças nos objectivos de desenho), e não vale a pena tentar juntá-los num só. + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/midi.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/midi.docbook new file mode 100644 index 00000000000..6ac91d58aa0 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/midi.docbook @@ -0,0 +1,524 @@ + + + +&MIDI; + + +Introdução + + + +O suporte de &MIDI; no &arts; poderá fazer uma quantidade de coisas. Primeiro que tudo, permite a comunicação entre as diversas peças de 'software' que produzem ou consomem eventos &MIDI;. Se você, por exemplo, tiver uma sequenciador e um reprodutor que funcionem com o &arts;, o &arts; poderá enviar os eventos &MIDI; do sequenciador para o reprodutor. + +Por outro lado, o &arts; pode também ajudar as aplicações a interagir com o 'hardware'. Se um dado bloco de 'software' (como, por exemplo, o suporte de amostragem) funcionar em conjunto com o &arts;, ele será capaz de receber os eventos &MIDI; de um teclado &MIDI; externo, da mesma forma. + +Finalmente, o &arts; dá um excelente sintetizador modular. Está desenhado para fazer exactamente isso. Por isso, você poderá criar instrumentos a partir de pequenos módulos com o 'artsbuilder', e usar depois esses instrumentos para compor ou tocar música. A síntese poderá não ser pura, dado que existem módulos que você poderá usar para tocar amostras. Por isso, o &arts; poderá ser um reprodutor de amostras, um sintetizador, entre outras coisas e, sendo completamente modular, é muito fácil de extender, muito fácil de experimentar, poderoso e flexível. + + + +O Gestor de &MIDI; + + +A componente central no &arts; que mantém o registo das aplicações que estão ligadas e como é que os eventos deverão ser passados entre elas é o gestor MIDI. Para ver ou influenciar o que ela faz, inicie o 'artscontrol'. Depois, escolha VerVer o Gestor de MIDI no menu. + +Do lado esquerdo, você verá as Entradas MIDI. Aí, todos os objectos que produzam eventos &MIDI;, como por exemplo um porto &MIDI; que envie dados vindos de um teclado &MIDI; ligado, um sequenciador que toque uma música, entre outras coisas, serão aqui listados. Do lado direito, você verá as Saídas MIDI. Aqui, todas as coisas que consumam eventos &MIDI;, como um reprodutor de amostras simulado (como 'software') ou o porto &MIDI; externo onde o seu reprodutor por 'hardware' estará ligado, serão listadas. As aplicações novas, como os sequenciadores registar-se-ão elas próprias, de modo a que la lista vai sendo actualizada ao longo do tempo. + +Você poderá ligar as entradas às saídas se você marcar a entrada do lado esquerdo e a saída do lado direito, escolhendo em seguida Ligar com o botão em baixo. O Desligar funciona da mesma forma. Você irá ver o que está ligado como pequenas linhas entre as entradas e as saídas, no meio da janela. Tenha em atenção que você poderá ligar um emissor a mais do que um receptor (e vice-versa). + +Os programas (como o sequenciador Brahms) adicionar-se-ão eles próprios quando são iniciados e serão removidos da lista quando terminarem. Mas você também poderá adicionar itens novos no menu Adicionar: + + + +Porto MIDI do Sistema (OSS) + +Isto irá criar um novo objecto do &arts; que fala com um porto MIDI externo. + +Dado que os portos MIDI externos podem fazer ambas as coisas (enviar e receber dados), a escolha desta opção irá adicionar uma entrada e uma saída MIDI. No &Linux;, você deverá ter um controlador OSS (ou OSS/Free, o que vem com o 'kernel' do seu &Linux;) ou um ALSA instalado para a sua placa de som, para que isto funcione. Ele irá perguntar o nome do dispositivo. Normalmente, este é o /dev/midi ou o /dev/midi00. + +Contudo, se você tiver mais do que um dispositivo &MIDI; ou &MIDI; local instalado, poderão existir mais opções. Para ver mais informações sobre os seus portos &MIDI;, inicie o &kcontrolcenter; e escolha Informação Som. + + + + +Saída MIDI de Sintetização do aRts + +Isto irá adicionar uma nova saída &MIDI; com um instrumento sintetizado do &arts;. Se você escolher o item do menu, aparecerá uma janela que lhe permite escolher um instrumento. Você poderá criar instrumentos novos com o 'artsbuilder'. Todos os ficheiros .arts com um nome que comece por instrument_ irão aparecer aqui. + + + + + + + +Usar o &arts; & o Brahms + +De facto, começar é bastante fácil. Você irá precisar de uma versão para o &kde; 2.1 ou superior do &brahms;, a qual poderá ser encontrada no módulo kmusic do CVS. Existe também algumas informações sobre como obter o &brahms; na Página Pessoal do aRts na secção 'Download' (Transferir). + +Quando você o inicia, irá aparecer no gestor de &MIDI;. Se você quiser fazer síntese, basta adicionar um instrumento sintetizado &MIDI; através da opção AdicionarSaída MIDI de Síntese do aRts. + +Escolha um instrumento (por exemplo, o organ2). Ligue-os com o botão Ligar. Finalmente, poderá começar a compor no &brahms;, para que o resultado seja sintetizado com o &arts;. + +Normalmente, é uma boa ideia ter a janela do &artscontrol; aberta e ver se o volume não está muito alto (a qualidade piora quando as barras tocam no limite superior). Agora, você poderá começar a trabalhar numa música de demonstração do &arts; e, se estiver pronto, podê-la-á publicar no aRts-project.org ;-). + + + + + + +midisend + +O midisend é uma pequena aplicação que lhe permitirá enviar eventos de &MIDI; a partir da linha de comandos. Ele registar-se-á como cliente, tal como acontece com as outras aplicações. A forma mais simples de o usar é % midisend /dev/midi00 , o qual irá fazer mais ou menos o mesmo que adicionar um porto &MIDI; do sistema no &artscontrol;. (Nem por isso, porque o midisend só envia eventos). A diferença é que é fácil, por exemplo, iniciar o midisend em vários computadores diferentes (e, por isso, usar a transparência na rede). + +Também é possível fazer com que o midisend envie os dados a partir do stdin, o qual poderá usar para encaminhar os dados das aplicações que não conhecem o &arts;, como a seguinte: % aplicacao_que_produz_eventos_midi_no_stdout | midisend + + + + + + +Criar Instrumentos + +A forma como o &arts; faz a síntese de &MIDI; é a seguinte: você tem uma estrutura com alguns portos de entrada, onde ele vai obter a frequência, a velocidade (volume) e um parâmetro que indica se a nota ainda continua carreada. A estrutura deverá agora sintetizar exactamente a nota com esse volume e reagir ao parâmetro 'pressed' (pressionado) (onde o 'pressed' = 1 significa que o utilizador ainda mantém essa tecla carregada e o 'pressed' = 0 significa que o utilizador soltou a tecla). + +Quando os eventos &MIDI; chegam, o &arts; irá criar novas estruturas para as notas à medida das necessidades, passar-lhes os parâmetros, e limpá-las quando terminar. + +Para criar e usar uma dessas estruturas, você deverá fazer o seguinte: + + + +Para começar, a forma mais conveniente é abrir o ficheiro template_Instrument.arts no &arts-builder;. + +Isto poderá ser obtido se usar o FicheiroAbrir um Exemplo... e escolher o template_Instrument no selector de ficheiros. Isto dar-lhe-á uma estrutura vazia com os parâmetros necessários, os quais você só terá de preencher. + + + +Para processar o parâmetro 'pressed', é conveniente usar o Synth_ENVELOPE_ADSR, ou, no caso de tocar apenas um WAV de uma bateria, simplesmente tocá-lo, ignorando deste modo o parâmetro 'pressed'. + + + +A estrutura deverá indicar quando já não é necessária na saída done (pronto). Se o 'done' for igual a 1, o &arts; irá assumir que pode remover a estrutura. Convenientemente, o envelope de ADSR fornece um parâmetro quando tiver terminado, por isso só precisa de ligar isto à saída 'done' da estrutura. + + + +Você deverá mudar o nome da sua estrutura para algum nome que comece por instrument_, como por exemplo instrument_piano.arts - você deverá gravar o ficheiro com o mesmo nome na sua pasta $HOME/arts/structures (a qual é onde o 'artsbuilder' normalmente deseja gravar os ficheiros). + + + +Finalmente, logo que o tenha gravado, você será capaz de o usar com o &artscontrol; no gestor de &MIDI;. + + + +Ah, e claro que a sua estrutura deverá tocar os dados de áudio que gera nas saídas esquerda e direita da estrutura, as quais serão por sua vez tocadas no gestor de áudio (você poderá ver isso no &artscontrol;), para que o consiga ouvir finalmente (ou processá-lo posteriormente com efeitos). + + + +Uma boa forma de aprender como criar instrumentos é abrir um instrumento existente através da opção FicheiroAbrir um Exemplo e ver como funciona ;) + + + +Instrumentos Mapeados + +Os instrumentos mapeados são os que se comportam de forma diferente, dependo da frequência, do programa, do canal ou da velocidade. Você poderá ter por exemplo um piano de 5 oitavas, usando uma amostra por cada oitava (ajustando a frequência, de acordo com isso). Isto irá soar bastante melhor do que usar apenas uma amostra. + +Você poderá criar também um mapa de bateria, o qual toca uma amostra específica da bateria por tecla. + +Finalmente, é muito útil se você tocar vários sons diferentes num instrumento mapeado em programas diferentes. Desta forma, você poderá usar o seu sequenciador, teclado externo ou outra fonte &MIDI; para mudar de sons sem ter de ajustar o &arts; à medida que trabalha. + +Um bom exemplo para isso é o instrumento arts_all, o qual apenas reúne todos os instrumentos que vêm com o &arts; num mapa. Desta forma, você apenas terá de configurar uma vez o &artscontrol; para usar este instrumento, e assim, poderá compor uma música inteira num sequenciador sem ter de se incomodar com o &arts;. Precisa de outro som? Basta escolher o programa no sequenciador, para que o &arts; lhe dê outro som. + +Criar esses mapas é relativamente simples. Você apenas precisa de criar um ficheiro de texto e escrever regras que se assemelhem a isto: + +ON [ condições ...] DO structure=uma_estrutura.arts + + +As condições poderão ser uma ou mais das seguintes: + + + + + + + +A frequência ou tom que é tocado. Você poderá usar isto se quiser dividir o seu instrumento com base no tom. No exemplo inicial, um piano que use amostras diferentes para as várias oitavas iria usar isto como condição. Você poderá indicar uma frequência única, como por exemplo =62 ou um intervalo de frequências, como por exemplo =60-72. Os tons possíveis situam-se entre 0 e 127. + + + + + + +O programa que está activo no canal para onde a nota vai ser enviada. Normalmente, os sequenciadores permitem-lhe escolher o instrumento através da opção 'program'. São permitidos programas únicos ou intervalos de programas, isto é, por exemplo, =3 ou =3-6. Os programas possíveis situam-se entre 0 e 127. + + + + + + +O canal para onde a nota vai ser enviada. São permitidos canais únicos ou intervalos, isto é, por exemplo, =0 ou =0-8. Os canais possíveis situam-se entre 0 e 15. + + + + + + +A velocidade (volume) que a nota tem. São permitidas velocidades únicas (quem irá usar isso?) ou intervalos, como por exemplo =127 ou =64-127. As velocidades possíveis situam-se entre 0 e 127. + + + + +Um exemplo completo para um mapa seria (este é extraído do ficheiro instrument_arts_all.arts-map actual): + +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 + + +Como você poderá ver, a estrutura é seleccionada, dependendo do programa. No programa 11, você vê um mapa de bateria (com dois itens), o qual irá tocar um bombo com o C-5 (pitch=60), e um prato de choque com o C#5 (pitch=61). + +Para fazer com que os ficheiros dos mapas apareçam automaticamente no &artscontrol; como opções dos instrumentos, terão de se chamar instrument_qualquercoisa.arts-map e estarem na sua Pasta Pessoal, em $HOME/arts/structures, ou na pasta do &kde; em $KDEDIR/usr/local/kde/share/apps/artsbuilder/examples. As estruturas que são usadas no mapa poderão ser indicadas com a sua localização absoluta ou então relativa à pasta onde o ficheiro de mapa se encontra. + +Extender o mapa 'arts_all map' ou mesmo criar um mapa geral &MIDI; completo para o &arts; é uma boa ideia para tornar o &arts; mais simples de usar por-si-só. Pense por favor em contribuir com instrumentos interessantes que faça, de modo a que possam ser incluídos nas versões futuras do &arts;. + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/midiintro.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/midiintro.docbook new file mode 100644 index 00000000000..fc9b9712a68 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/midiintro.docbook @@ -0,0 +1,16 @@ + + + + +Introdução ao <acronym +>MIDI</acronym +> + +Ainda não escrito + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/modules.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/modules.docbook new file mode 100644 index 00000000000..d1fd309b052 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/modules.docbook @@ -0,0 +1,1329 @@ + + + +Módulos do &arts; + + +Introdução + +Este capítulo descreve todos os módulos normais do &arts;. Sendo uma das funcionalidades mais poderosas do &arts;, os módulos podem ser ligados em conjunto através de estruturas para implementar novas funções como efeitos e instrumentos. + +Os módulos são divididos em duas categorias. Os módulos de síntese são usados para implementar a canalização que manipula as sequências de dados multimédia para implementar novos efeitos, instrumentos, misturadores e aplicações. Os módulos visuais permitem-lhe oferecer uma interface gráfica para o utilizador poder controlar as estruturas de som que são criadas com os módulos de síntese. + + + + +Referência dos Módulos de Síntese + + + +Aritmética + Mistura + + + + +Synth_ADD + + + + + +Synth_ADD + + +Isto adiciona dois sinais. + + + + +Synth_MUL + + + + + +Synth_MUL + + +Isto multiplica um sinal por um determinado factor. Você poderá usar isto para reduzir a amplitude dos sinais (0 < factor < 1) ou ampliá-los (factor > 1) ou ainda invertê-los (factor < 0). Tenha em atenção que o factor pode ser um sinal e não tem de ser constante (⪚ um sinal de envelope ou um sinal real). + + + + +Synth_DIV + + + + + +Synth_DIV + + +Isto divide um sinal por um dado facto. Poderá usar isto para dividir um sinal por outro. Pode definir também o valor1 como sendo 1 e irá obter o simétrico do valor2 como resultado. Tenha em atenção que o valor2 nunca deverá ser igual a 0, caso contrário irá ter problemas com divisões por zero. + + + + +Synth_MULTI_ADD + + + + + +Synth_MULTI_ADD + + +Isto adiciona uma quantidade arbitrária de sinais. Se você precisar de somar todas as formas de onda produzidas por quatro osciladores, você poderá ligar todas as saídas deles a um único módulo Synth_MULTI_ADD. Isto é mais eficiente do que usar três módulos Synth_ADD. + + + + +Synth_XFADE + + + + + +Synth_XFADE + + +Isto mistura dois sinais. Se o valor da percentagem for igual a -1, só o sinal esquerdo é ouvido; se for igual a 1, só o sinal direito é ouvido. Se for 0 (zero), ambos os sinais são ouvidos com o mesmo volume. + +Isto permite-lhe garantir que o seu sinal permanece num intervalo bem definido. Se você tiver dois sinais que estejam entre -1 e 1 antes da mistura, eles irão permanecer dentro do mesmo intervalo após a dita mistura. + + + +Synth_AUTOPANNER + + +O oposto de um 'crossfader'. Este recebe um sinal mono e divide-o num sinal estéreo: É usado para deslocar automaticamente o sinal à entrada entre a saída esquerda e a direita. Isto torna as misturas mais vivias. Uma aplicação normal seria uma guitarra ou um som principal. + +Ligue um LFO, uma onda sinusoidal ou dente-de-serra por exemplo ao 'inlfo'. e seleccione uma frequência entre 0,1 e 5Hz para um efeito tradicional ou mais ainda para efeitos especiais. + + + + + + +Barramentos + + +Synth_BUS_UPLINK + + + + + +Synth_BUS_UPLINK + + +Um canal de envio para um barramento. Forneça os sinais ao 'left' (esquerdo) e ao 'right' (direito), bem como o nome do barramento onde os dados deverão ir no porto bus. O sinal combinado de todos os canais de envio ('uplinks') irão aparecer em todos os canais de recepção ('downlinks') desse barramento. + + + +Synth_BUS_DOWNLINK + + + + + +Synth_BUS_DOWNLINK + + +Obtém (a soma de) todos os dados que são colocados num determinado barramento (com o nome que você indicar no porto bus (barramento)). + + + + + + + +Atrasos + + + + +Synth_DELAY + + + + + +Isto atrasa o sinal de entrada por um período de tempo determinado. A especificação do tempo deverá ser entre 0 e 'maxdelay' (atraso máximo) para obter um atraso equivalente em segundos. + +Este tipo de atrasos não pode ser usado nas estruturas de realimentação ('feedback'). Isto acontece por ser um atraso variável. Você poderá modificar o seu tamanho enquanto corre e até mesmo configurá-lo como sendo zero. Mas como numa estrutura de realimentação a própria saída é necessária para calcular as próximas amostras, uma atraso cujo valor possa cair para zero durante a síntese poderá conduzir a uma situação de paragem. + +Use os CDELAYs nesse caso, e combinando talvez um atraso constante (de 0,001 segundos) com um atraso flexível. + +Você poderá também combinar um CDELAY com um DELAY para obter um atraso de tamanho variável com um valor mínimo num ciclo de realimentação. Certifique-se apenas que tem um CDELAY. + + + + +Synth_CDELAY + + + + +Synth_CDELAY + + +Isto atrasa o sinal de entrada por um período de tempo determinado. A especificação do tempo deverá ser maior que 0 para obter um atraso de 0 segundos ou mais. O atraso é constante durante o cálculo, o que significa que ele não poderá ser modificado. + +Isto poupa no tempo de cálculo, atendendo a que não é feita nenhuma interpolação e é útil para estruturas recursivas. Veja a descrição acima (Synth_DELAY). + + + + + + +Envelopes + + + + +Synth_ENVELOPE_ADSR + + + + +Synth_ENVELOPE_ADSR + + +Este é um envelope clássico de ADSR, o que significa que você indica: + + + +active + +Se a nota está a ser carregada de momento pelo utilizador. + + + + +invalue + +O sinal de entrada. + + + + +attack + +O tempo que deverá passar entre o utilizador carregar na nota e o sinal atingir a sua amplitude máxima (em segundos). + + + + +decay + +O tempo que deverá passar entre o sinal atingir a sua amplitude máxima e o sinal a voltar para um nível constante (em segundos). + + + + +sustain + +O nível constante em que o sinal é mantido até que o utilizador solte a nota. + + + + +release + +O tempo que deverá passar depois de o utilizador soltar a nota até que o sinal seja reduzido até zero (em segundos). + + + + +Você irá obter o sinal redimensionado em 'outvalue' (na saída). Se o envelope do ASDR tiver terminado, irá colocar o 'done' (terminado) a 1. Você poderá usar isto para fornecer a saída done de um instrumento (que fará com que a estrutura do instrumento seja removida pelo encaminhador de &MIDI; logo que a fase do 'release' tenha terminado). + + + + +Synth_PSCALE + + + + +Synth_PSCALE + + +O módulo Synth_PSCALE irá aplicar um factor de escala ao canal de áudio que passa por ele, desde um volume 0 (silêncio) até o 1 (volume original), e de volta a 0 (silêncio). De acordo com a posição (pode obter a posição a partir de Synth_SEQUENCE). A altura em que o pico deverá ocorrer poder ser indicada em 'pos'. + +Exemplo: Se definir o 'top' igual a 0,1 significa que, ao fim de 10% da nota ter sido tocada, o volume atingiu o seu máximo e começa a decair a partir daí. + + + + + +Efeitos + + +Synth_FREEVERB + + + + +Synth_FREEVERB + + +Este é um efeito de reverberação. Na implementação actual, passa um sinal estéreo através do efeito, adicionando a tal reverberação ao mesmo sinal. + + +Isto significa que ele também poderá ser usado numa StereoEffectStack. + + +O sinal de entrada deverá ser ligado a (inleft, inright) e o de saída a (outleft, outright). + +Os parâmetros que você poderá configurar são: + + + +roomsize + +O tamanho da sala que a reverberação irá simular (intervalo: 0..1, em que o 1 é a maior sala possível). + + + + +damp + +Isto indica um filtro que fará com que a sala simulada absorva as altas frequências (intervalo de 0..1, em que o 1 significa que as altas frequências são absorvidas de forma agressiva). + + + + +wet + +A quantidade de sinal reverberado (isto é, a quantidade de sinal que deverá ser modificado pelos filtros, resultando num som molhado. + + + + +dry + +A quantidade de sinal puro que é passado, resultando num eco (ou atraso combinado), em vez de ser afectado por reverberação (intervalo: 0..1). + + + + + +largura + +A quantidade de efeito de estéreo que o algoritmo de reverberação adiciona ao efeito, tornando o som reverberado mais amplo no panorama estéreo (intervalo: 0..1). + + + + +modo + +[ TODO: Pensa-se que, se o 'mode' for igual a 1, a reverberação mantém a imagem actual do som, e onde o 0 é a operação normal ] + + + + + + + +Synth_TREMOLO + + + +Synth_TREMOLO + + +O módulo 'tremolo' modula a amplitude com base numa onda LFO. Tradicionalmente você iria usar uma onda sinusoidal, mas porquê limitar-se? O que irá obter é um efeito muito intenso que corta a maioria dos arranjos devido ao seu efeito altamente dinâmico. O efeito de 'tremolo' é ainda um dos efeitos favoritos dos guitarristas, ainda que não seja tão popular como era nos anos 60. + +[ TODO: de momento, isto está implementado como 'invalue + abs(inlfo)' - provavelmente faria mais sentido se fosse implementado como 'invalue * (1+inlfo*depth)', onde o 'depth' (profundidade) seria um parâmetro entre 0..1 - isto poderá ter sido decidido após o &kde;2.1 ; se tiver um comentário, envie uma mensagem para a lista do &arts; ;). ] + + + +Synth_FX_CFLANGER + + + +Synth_FX_CFLANGER + + +Um 'flanger' é um efeito de atraso variável no tempo. Para tornar o desenvolvimento de efeitos complexos de 'flanger' mais simples, é fornecido este módulo que contém a base de um 'flanger' de um canal. + +Ele contém os seguintes portos: + + + +invalue + +O sinal que você deseja processar. + + + + +lfo + +De preferência, uma onda sinusoidal que modula o tempo de atraso no 'flanger' (-1 .. 1). + + + + +mintime + +O valor mínimo para o atraso no 'flanger' em milisegundos. Valores sugeridos: tente algo do género 1 ms. Por favor use valores < 1000 ms. + + + + +maxtime + +O valor máximo para o atraso no 'flanger' em milisegundos. Valores sugeridos: tente algo do género 5 ms. Por favor use valores < 1000 ms. + + + + +outvalue + +O sinal de saída. É importante que você misture isso com o sinal original para obter o efeito desejado. + + + + + +Você poderá usar isto com base para um efeito de coro. + + + + + + + +Filtros + + +Synth_PITCH_SHIFT + + + +Synth_PITCH_SHIFT + + +Este efeito de mudança de frequência altera a frequência do sinal da entrada sem afectar a velocidade. Uma aplicação para isto é por exemplo a alteração do toma da sua voz enquanto você a grava (e reproduz) em tempo-real. + +O parâmetro speed (velocidade) é a velocidade relativa com que o sinal será reproduzido. Deste modo, uma velocidade igual a dois fará com que o som fique duas vezes mas alto (&ie; uma frequência de entrada de 440 Hz iria resultar numa frequência de saída de 880 Hz). + +O parâmetro frequency (frequência) é usado internamente para mudar entre as várias diferenças do sinal. É ajustável e, dependendo da sua escolha, o desvio de frequência parecerá mais ou menos realístico para o seu caso de uso. Um bom valor para começar será algo do tipo 5 ou 10. + + + + +Synth_SHELVE_CUTOFF + + + +Synth_SHELVE_CUTOFF + + +Filtra todas as frequências superiores à frequência de corte. + + + + +Synth_BRICKWALL_LIMITER + + + +Synth_BRICKWALL_LIMITER + + +Este módulo corta um sinal, de modo a fazer com que ele caiba no intervalo [-1;1]. Ele não faz nada para evitar a distorção que acontece ao cortar os sinais altos. Você poderá usar isto como um efeito (por exemplo, para criar uma onda sinusoidal ligeiramente cortada). Contudo, é provavelmente uma boa ideia passar o sinal através de um filtro passa-baixo depois disso, para tornar o som menos agressivo. + + + +Synth_STD_EQUALIZER + + + +Synth_STD_EQUALIZER + + +Este é um bloco de equalização parametrizado engraçado. Os seus parâmetros são: + + + +invalue, outvalue + +O sinal que é filtrado pelo equalizador. + + + + +low + +Como é que as frequências baixas deverão ser alteradas. O valor está em dB, e onde 0 significa que as baixas frequências não são alteradas, o -6 significa que as reduzirá em 6dB, e o +6 significa que as aumenta em 6dB. + + + + +mid + +Como é que as frequências intermédias deverão ser alteradas pelo equalizador (ver em 'low'). + + + + +high + +Como é que as altas frequências deverão ser alteradas pelo equalizador (ver em 'low'). + + + + +frequency + +Esta é a frequência central do equalizador em Hz, onde as frequências intermédias se situam à volta desse espectro, tendo as baixas frequências à sua esquerda e as altas à direita. Tenha em atenção que a frequência não poderá ser mais elevada que metade da taxa de amostragem; normalmente esta é igual a 22 050 Hz e não poderá ser menor que 1 Hz. + + + + +q + +Isto influencia quão estreito é o espectro central. Deverá ser um número positivo > 0. Um valor igual a um é razoável, os valores mais elevados correspondem a um espectro mais estreito de frequências intermédios e os menores que um correspondem a um espectro largo. + + + + + + + +Synth_RC + + + +Synth_RC + + +Um filtro por ressonância filtra todas as frequências à volta de um determinado valor de pico. Não existe nenhuma forma útil de indicar a frequência intermédia (a que não será cortada), dado que as entradas são duas constantes estranhas 'f' e 'b'. O código é muito antigo, desde os primeiros dias do sintetizador, e provavelmente será substituído por um filtro novo que terá um frequência e um valor de ressonância como parâmetros). + +Tente algo do género b=5, f=5 ou b=10, f=10 ou b=15, f=15, todavia. + + + + +Synth_MOOG_VCF + + + +Synth_MOOG_VCF + + +Filtra todas as frequências acima da frequência de corte (é um filtro de 24dB com 4 pólos, o qual filtra -24db por oitava acima da frequência de corte), mas oferece um parâmetro adicional para ajustar a ressonância do filtro, em que o 0 significa ausência de ressonância e o 4 significa auto-oscilação. + + + + + + +MIDI + Sequenciação + + +Synth_MIDI_TEST + + + +Synth_MIDI_TEST + + +Este módulo carrega uma estrutura de um instrumento a partir de um ficheiro e regista-se como uma saída de MIDI com o gestor de &MIDI; do &arts;. As notas que são enviadas para esta saída irão resultar na criação de vozes dos instrumentos. + + +Você poderá configurar algo mais conveniente no &artscontrol; do que fazê-lo manualmente no &arts-builder;. + + + + + +Synth_SEQUENCE + + + + +Irá tocar uma sequência de notas outra e outra vez. As notas são dadas na notação de teclado e são separadas por ponto-e-vírgula. Um exemplo será A-3;C-4;E-4;C-4;. A velocidade é dada em segundos por nota, por isso, se você quiser 120 batidas por minuto, você deverá indicar provavelmente 0,5 segundos por nota, dado que 60 segundos/0,5 segundos por nota=120 bpm. + +Você poderá indicar em cada nota um tamanho relativo à velocidade adicionado dois pontos (:) a seguir à nota, seguido do tamanho. O A-3:2;C-4:0.5;D-4:0.5;E-4; demonstra isto. Como pode ver, os programas de composição de &MIDI; tendem a oferecer mais conforto ;) + +O Synth_SEQUENCE dá-lhe informações adicionais sobre a posição da nota que está a tocar de momento, onde o 0 indica que iniciou agora e o 1 que terminou. Esta informação poderá ser usada no Synth_PSCALE (veja em baixo). + + + +Synth_SEQUENCE_FREQ + + + + +Este módulo funciona tal-e-qual o Synth_SEQUENCE com a única diferença que você não indica nomes de notas mas sim frequências. + + + + + + +Amostras + + +Synth_PLAY_WAV + + + + +Synth_PLAY_WAV + + +Isto irá tocar um ficheiro wav. Isto só estará presente se você tiver a 'libaudiofile' instalada no seu computador. O ficheiro WAVE iniciar-se-á logo que o módulo for criado. + +Irá parar logo que tenha terminado, situação em que o 'finished' (terminado) será posto a 1. O parâmetro 'speed' (velocidade) pode ser usado para reproduzir o ficheiro mais depressa ou mais devagar, e onde o 1,0 é a velocidade normal (com que foi gravado). + + + + + + +E/S de Som + + +Synth_PLAY + + + + +Synth_PLAY + + + +Você normalmente não irá necessitar deste módulo, a menos que esteja a criar aplicações autónomas. Dentro do &artsd;, existe já um módulo Synth_PLAY e, se criar outro, este não irá funcionar. + + +O módulo Synth_PLAY irá enviar o seu sinal de áudio para a placa de som. Os canais 'left' (esquerdo) e 'right' (direito) deverão conter a entrada normalizada dos canais. Se a sua entrada não estiver entre -1 e 1, será cortado o sinal. + +Como já foi referido, só pode existir um módulo Synth_PLAY em uso, dado que este acede directamente à sua placa de som. Utilize os barramentos se você quiser misturar mais do que um canal de áudio em conjunto antes de o reproduzir. Use o módulo Synth_AMAN_PLAY para obter algo semelhante a uma saída no &artsd;. + +Tenha em atenção que o Synth_PLAY também faz a temporização da estrutura completa. Isto significa: sem Synth_PLAY = sem fonte de temporização = sem som. Por isso, você irá necessitar (exactamente) de um objecto Synth_PLAY. + + + + +Synth_RECORD + + + +Synth_RECORD + + + +Você normalmente não irá necessitar deste módulo, a menos que esteja a criar aplicações autónomas. Dentro do &artsd;, existe já um módulo Synth_RECORD e, se criar outro, este não irá funcionar. + + +O módulo Synth_RECORD irá gravar um sinal proveniente da placa de som. Os canais 'left' (esquerdo) e 'right' (direito) irão conter a entrada dos canais (entre -1 e 1). + +Como já foi referido, só pode existir um módulo Synth_RECORD em uso, dado que este acede directamente à sua placa de som. Utilize os barramentos se você quiser usar os canais de áudio gravados em mais do que um sítio. Use o módulo Synth_AMAN_RECORD para obter algo semelhante a uma entrada no &artsd;. Para isto funcionar, o &artsd; terá de estar a correr com o 'full duplex' activo. + + + +Synth_AMAN_PLAY + + + +Synth_AMAN_PLAY + + +O módulo Synth_AMAN_PLAY irá enviar para a saída o seu sinal de áudio. É bom (mas não necessário) se você enviar para fora um sinal normalizado (entre -1 e 1). + +Este módulo irá usar o gestor de áudio para atribuir onde o sinal será tocado. O gestor de áudio poderá ser controlado através do &artscontrol;. Para o tornar mais intuitivo no seu uso, é bom dar ao sinal que tocar um nome. Isto poderá ser obtido através da opção title (título). Outra funcionalidade do gestor de áudio é ser capaz de se recordar onde tocou um dado sinal da última vez. Para o fazer, ele precisa de ser capaz de distinguir os sinais. É por isso que você deverá atribuir algo único ao autoRestoreID, também. + + + +Synth_AMAN_RECORD + + + +Synth_AMAN_RECORD + + +O módulo Synth_AMAN_RECORD irá gravar um sinal de áudio de uma fonte externa (&ie;. 'line in'/'microfone') para dentro do &artsd;. O resultado será um sinal normalizado (entre -1 e 1). + +Este módulo irá usar o gestor de áudio para atribuir onde o sinal será tocado. O gestor de áudio poderá ser controlado através do &artscontrol;. Para o tornar mais intuitivo no seu uso, é bom dar ao sinal que gravar um nome. Isto poderá ser obtido através da opção title (título). Outra funcionalidade do gestor de áudio é ser capaz de se recordar onde gravou um dado sinal da última vez. Para o fazer, ele precisa de ser capaz de distinguir os sinais. É por isso que você deverá atribuir algo único ao autoRestoreID, também. + + + +Synth_CAPTURE + + + +Synth_CAPTURE + + +O módulo Synth_CAPTURE irá gravar um sinal de áudio num ficheiro WAVE no seu disco rígido. O ficheiro será sempre chamado de /tmp/mcop-utilizador/capture.wav + + + + + +Testes + + +Synth_NIL + + + +Synth_NIL + + +Isto simplesmente não faz nada. Só é útil para situações de teste. + + + + +Synth_DEBUG + + + +Synth_DEBUG + + +Você poderá usar isto para depuração. Ele irá imprimir o valor do sinal em 'invalue' em intervalos regulares (p.ex. a cada 1 segundo), combinado com o comentário que você indicou. Desta forma, você poderá descobrir se alguns dos sinais estão dentro de determinados intervalos ou se estão lá mesmo de todo. + + + +Synth_MIDI_DEBUG + + + +Synth_MIDI_DEBUG + + +Você poderá usar isto para depurar como é que os seus eventos &MIDI; estão a chegar ao &arts;. + +Quando um MIDI_DEBUG estiver a correr, o &artsserver; irá imprimir linhas do tipo: + +201 100753.837585 on 0 42 127 + +202 101323.128355 off 0 42 + +Enquanto que a primeira linha lhe diz que 100753ms (isto é, 100 segundos) depois de o MIDI_DEBUG começar, chegou um evento 'on' de &MIDI; no canal 0. Este evento tinha a velocidade (volume) de 127, a mais elevada possível. A linha a seguir mostra o evento de libertação do MIDI. [ TODO: isto não funciona de momento, quando funcionar, deverá ser feito através do gestor de &MIDI; ]. + + + +Synth_DATA + + + +Synth_DATA + + +Isto cria um sinal com um número constante. + + + + + +Oscilação & Modulação + + +Synth_FREQUENCY + + + +Synth_FREQUENCY + + +Todos os osciladores no &arts; não precisam de uma frequência à entrada, mas si de uma posição na onda. A posição deverá ser entre 0 e 1, o que se mapeia num objecto normal do Synth_WAVE_SIN no intervalo 0..2*pi. Para gerar os valores oscilantes para uma frequência, é usado um módulo Synth_FREQUENCY. + + + +Synth_FM_SOURCE + + + +Synth_FM_SOURCE + + +Isto é usado na modulação de frequência. Coloque a sua frequência na entrada 'frequency' (frequência) e coloque outro sinal na entrada 'modulator'. Depois disso, defina o 'modlevel' (nível de modulação) para algo do género 0,3. A frequência será então modulada com o 'modulator'. Pode experimentar. Funciona bem mesmo quando você coloca uma realimentação nele, o que significa ter uma combinação do sinal de saída atrasado com o Synth_FM_SOURCE (você terá de o pôr com algum oscilador, dado que só tem o papel do Synth_FREQUENCY) e algum outro sinal para obter bons resultados. + +Funciona optimamente em conjunto com os osciladores Synth_WAVE_SIN. + + + + + +Formas de Onda + + +Synth_WAVE_SIN + + + +Synth_WAVE_SIN + + +Oscilador sinusoidal. Coloque um sinal 'pos' de um Synth_FREQUENCY ou de um Synth_FM_SOURCE à entrada. Deste modo, poderá obter uma onda sinusoidal à saída. O sinal 'pos' indica a posição de fase na onda, e pertence ao intervalo 0..1, que se mapeia internamente em 0..2*PI. + + + + +Synth_WAVE_TRI + + + +Synth_WAVE_TRI + + +Oscilador de ondas triangulares. Coloque um sinal 'pos' de um Synth_FREQUENCY ou de um Synth_FM_SOURCE à entrada. Deste modo, poderá obter uma onda sinusoidal à saída. O sinal 'pos' indica a posição de fase na onda, e pertence ao intervalo 0..1, que se mapeia internamente em 0..2*PI. Tenha cuidado, porque o sinal de entrada tem de estar no intervalo 0..1 para que o sinal de saída produza bons resultados. + + + +Synth_NOISE + + + +Synth_NOISE + + +Um gerador de ruído. Isto gera um sinal aleatório entre -1 e 1. + + + + +Synth_WAVE_SQUARE + + + +Synth_WAVE_SQUARE + + +Oscilador de ondas quadradas. Coloque um sinal 'pos' de um Synth_FREQUENCY ou de um Synth_FM_SOURCE à entrada. Deste modo, poderá obter uma onda sinusoidal à saída. O sinal 'pos' indica a posição de fase na onda, e pertence ao intervalo 0..1, que se mapeia internamente em 0..2*PI. Tenha cuidado, porque o sinal de entrada tem de estar no intervalo 0..1 para que o sinal de saída produza bons resultados. + + + +Synth_WAVE_SOFTSAW + + + +Synth_WAVE_SOFTSAW + + +Oscilador de ondas dente-de-serra. Coloque um sinal 'pos' de um Synth_FREQUENCY ou de um Synth_FM_SOURCE à entrada. Deste modo, poderá obter uma onda sinusoidal à saída. O sinal 'pos' indica a posição de fase na onda, e pertence ao intervalo 0..1, que se mapeia internamente em 0..2*PI. Tenha cuidado, porque o sinal de entrada tem de estar no intervalo 0..1 para que o sinal de saída produza bons resultados. + + + +Synth_WAVE_PULSE + + + +Synth_WAVE_PULSE + + +Oscilador de impulsos - este módulo é semelhante na ideia ao oscilador de ondas quadradas (Synth_WAVE_RECT), mas oferece uma relação configurável de nível alto/baixo, através do parâmetro dutycycle. Coloque um sinal 'pos' de um Synth_FREQUENCY ou de um Synth_FM_SOURCE à entrada. Deste modo, poderá obter uma onda sinusoidal à saída. O sinal 'pos' indica a posição de fase na onda, e pertence ao intervalo 0..1, que se mapeia internamente em 0..2*PI. Tenha cuidado, porque o sinal de entrada tem de estar no intervalo 0..1 para que o sinal de saída produza bons resultados. + + + +Diversos + + +Synth_COMPRESSOR + + + + + +Este módulo reduz o intervalo dinâmico do sinal. Por exemplo, os compressores são úteis na compensação das variações amplas de volume se alguém estiver a falar para um microfone. + +Assim que o nível de entrada exceder um dado nível (o patamar), o sinal é comprimido. Ele simplesmente multiplica tudo o que estiver acima do limite pelo valor de proporção, o qual é um número entre 0 e 1. Finalmente, o sinal completo é multiplicado pelo factor de saída. + +Os argumentos 'attack' e 'release' atrasam o início e o fim da compressão. Use isto se você, por exemplo, quiser à mesma ouvir o início forte de uma batida de bateria. O argumento está em milisegundos e um valor igual a 0ms é possível, se bem que poderá resultar apenas num ligeiro ruído. + + + + + + +Referência dos Módulos Visuais + +TODO quando os módulos visuais estiverem mais "completos". + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/porting.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/porting.docbook new file mode 100644 index 00000000000..03834e67b4c --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/porting.docbook @@ -0,0 +1,52 @@ + + + +Passar as Aplicações para o &arts; + + +Usar o &artsdsp; + +O utilitário &artsdsp;, descrito anteriormente, permite à maioria das aplicações de som legadas que falem directamente com os dispositivos de áudio, funcionarem convenientemente com o &arts;. As aplicações que foram criadas para usar o Enlightenment Sound Daemon (esd) irão também funcionar na maioria dos casos, se for executado o esd sobre o &artsdsp;. + +Isto possibilita uma solução a curto prazo para passar as aplicações existentes para o &kde;. Todavia, não permite que a aplicação tire directamente partido de todas as potencialidades do &arts;, como a utilização dos módulos e das sequências multimédia que não sejam apenas áudio digital. Se a aplicação necessitar de algo mais do que a reprodução de ficheiros de som, normalmente fará sentido adicionar o suporte nativo para o &arts; na aplicação. + +Ao usar o &arts; significa também que a aplicação não terá assim muito trabalho -- poderá remeter as funções para o &arts;, de modo a resolver alguns problemas, como por exemplo os codificadores para lidar com diferentes formatos multimédia e controlar o 'hardware' de som. + + + + +Adicionar o suporte nativo do &arts; + +Ao usar o &arts;, você tem um conjunto de APIs diferentes por onde escolher. A decisão de qual usar depende de um conjunto de factores, como o tipo de conteúdos multimédia a usar (som, &MIDI;, &CD; áudio, &etc;), as funcionalidades necessárias da API, e se é escrito em C++. Na maioria dos casos, a escolha deverá ser relativamente óbvia com base nas funcionalidades pedidas. + +Para uma portabilidade entre plataformas, as aplicações que precisem de correr noutros ambientes que não sejam o &kde;, não poderão confiar na presença do &arts;. Se usar o paradigma dos 'plugins' terá uma boa forma de suportar vários ambiente multimédia. Se tornar a API de 'plugins' aberta e documentada (especialmente para as aplicações com código fechado), terá também a vantagem de permitir que alguém que não o programador da aplicação implemente um 'plugin' do &arts;. + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/references.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/references.docbook new file mode 100644 index 00000000000..85eb7a70f53 --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/references.docbook @@ -0,0 +1,61 @@ + + + +Referências + + + + +http://multimedia.kde.org + +Esta é o 'site' Web principal para as informações relacionadas com multimédia do &kde;. + + + + +http://www.arts-project.org + +Esta é a página principal do projecto do &arts;. + + + + +Programação no &kde; 2.0 + +O Capítulo 14 deste livro publicado cobre o multimédia e inclui o &arts;. Está disponível impresso ou 'online' com anotações em http://www.andamooka.org. + + + + + +http://sound.condorow.net + +Este 'site' contém uma lista razoável de aplicações de som e de &MIDI; para o &Linux;. + + + + + + diff --git a/tde-i18n-pt/docs/kdemultimedia/artsbuilder/tools.docbook b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/tools.docbook new file mode 100644 index 00000000000..9cc6d2134fa --- /dev/null +++ b/tde-i18n-pt/docs/kdemultimedia/artsbuilder/tools.docbook @@ -0,0 +1,1007 @@ + + + +Ferramentas do &arts; + +Incluído com o &arts;, vem um conjunto de utilitários para controlar e configurar o seu comportamento. Você precisa de ter alguma familiaridade com a maioria dessas ferramentas para usar efectivamente o &arts;. Esta secção descreve cada um dos utilitários e as suas opções de comando. + + +&kcontrol; + +Ao correr o &arts; no &kde;, o &kcontrolcenter; oferece um grupo de opções do painel de controlo na categoria Som. Algumas dessas opções são usadas pelo &arts;. Você também poderá associar sons com vários eventos do gestor de janelas e do &kde; com o painel Aparência & ComportamentoNotificações do Sistema. Veja o manual do &kcontrol; para saber como usar as opções do painel. + + + + +&artsd; + +O acesso aos recursos de 'hardware' de som é controlado pelo &artsd;, o servidor do &arts;. Isto permite às várias aplicações enviarem pedidos simultâneos ao servidor, onde poderão ser misturados e tocados. Sem um servidor de som centralizado, uma única aplicação que usasse um dispositivo de som iria impedir que as outras aplicações o usassem também. + +Para usar o &arts;, deverá existir uma e apenas uma cópia do &artsd; a correr. É tipicamente executada quando o &kde; se inicia, se estiver activo no painel do &kcontrol; Servidor de Som do &kcontrol;. + +O programa aceita os seguintes argumentos: + + + +artsd + + + + +Indica a taxa de amostragem a usar. + + + + + + +Mostra a utilização dos comandos. + + + + + + +Activa a transparência na rede. + + + + + + + +Define o porto de TCP a usar (implica o ). + + + + + + +Público e sem autenticação (perigoso). + + + + + + +Activa a operação em 'full duplex'. + + + + + +Indica o dispositivo de áudio a usar (normalmente é o /dev/dsp). + + + + + + +Define o número de fragmentos. + + + + + + +Define o tamanho de cada fragmento em 'bytes'. + + + + + + +Define o tempo de suspensão automática do servidor, em segundos. Um valor igual a zero desactiva a suspensão automática. + + + + + + +Indica o nome de uma aplicação para usar para mostrar as mensagem de erro, de aviso e informativas. Se você estiver a correr o KDE, poderá usar o utilitário artsmessage para isto. + + + + + + +Aumenta o tamanho dos tampões de rede para um valor adequado para correr numa LAN de 10 Mbps. Isto é equivalente a usar a opção '-w 5' (ver em baixo). + + + + + +Ao correr o artsd sobre uma ligação de rede a outra máquina, você poderá querer usar um tamanho maior dos tampões ('buffers') para evitar cortes. O aRts fornece às aplicações um tamanho mínimo sugerido. Sem esta opção, o tamanho por omissão baseia-se no valor 'tamanho do fragmento' * 'número de fragmentos'. Se usar esta opção você poderá aumentar o tamanho predefinido por um factor de n. + + + + + + +Indica o nível de informações - 3 (silencioso), 2 (avisos), 1 (informação), 0 (depuração). + + + + + + +Mostra o número da versão. + + + + + +Na maioria dos casos, bastará correr o &artsd;. + + + +&artswrapper; + +Para oferecer uma boa resposta em tempo-real, o &artsd; é normalmente executado como um processo em tempo-real (nas plataformas que suportem prioridades de tempo-real). Isto necessita de permissões do root, por isso, para minimizar as implicações de segurança, o &artsd; poderá ser iniciado com o pequeno programa de interface &artswrapper;, o qual simplesmente configura a prioridade de tempo-real (correndo como root) e executa depois o &artsd; como um utilizador que não o root. + +Se você tornar o 'artswrapper' 'SUID' root, ele irá provavelmente melhorar a qualidade da sua reprodução de áudio, reduzindo os cortes na música. Contudo, aumenta também o risco de que um erro no código ou algum utilizador malicioso faça estoirar ou prejudicar o seu sistema. Para além disso, nas máquinas multi-utilizador, se prioritizar o áudio de alta-fidelidade poderá provocar uma perda de 'performance' para os utilizadores que estão a tirar partido produtivo da máquina. + + + + +&artsshell; + +O comando &artsshell; pretende ser um utilitário para efectuar diversas funções relacionadas com o servidor de som. Pretende-se que o utilitário seja extendido com comandos novos no futuro (veja os comentários no código-fonte para ter algumas ideias). + +O comando aceita o seguinte formato: + + + +artsshell suspendstatus terminate autosuspend segundos networkbuffers n volume [volume] stereoeffect opções + +artsshell [options] comando [opções do comando] + +São suportadas as seguintes opções: + + + + + + +Suprime todos os resultados. + + + + + + +Mostra a utilização dos comandos. + + + + + +São suportados os seguintes comandos: + + + + + + +Suspende o servidor de som. + + + + + + +Mostra a informação de estado do servidor de som. + + + + + + +Termina o servidor de som. Isto poderá confundir e/ou estoirar as aplicações que o estejam a usar no momento. + + + + + segundos + +Configura o tempo de suspensão automática para o número de segundos indicado. O servidor de som suspender-se-á se estiver inactivo durante esse período de tempo. Um valor igual a zero desactiva a suspensão automática. + + + + + n + +Define o tamanho dos tampões de rede para ser um facto de n vezes o tamanho predefinido. + + + + + [volume] + +Altera o factor de escala para as saídas de áudio do servidor de som. O argumento volume é um valor de vírgula flutuante. Sem argumentos, é mostrado o volume actual. + + + + + + +Mostra todos os módulos de efeitos estéreo disponíveis. + + + + + nome + +Introduz um efeito estéreo na pilha de efeitos. Devolve um identificador que poderá ser usado para o remover posteriormente. Poderá ser instalado no topo ou no fundo (o valor por omissão). + + + + + identificador + +Remove o efeito estéreo com o identificador identificador da pilha de efeitos. + + + + + + + + +<application +>artsplay</application +> + +O comando artsplay é um utilitário simples para tocar um ficheiro de som. Ele aceita um único argumento que corresponde ao nome de um ficheiro de som que é enviado para o servidor de som de modo a ser tocado. O ficheiro de som poderá ser qualquer tipo de ficheiro de som comum como o wav ou o au. Este utilitário é bom para testar se o servidor de som está a funcionar. Se correr dois comandos em paralelo ou em sucessão rápida, você poderá demonstrar como os servidores de som misturam mais do que uma fonte. + + + + +<application +>artsdsp</application +> + +O servidor de som só suporta as aplicações que tirem partido do &arts;. Muitas das aplicações legadas querem aceder ao dispositivo de som directamente. O comando &artsdsp; oferece uma solução intermédia que permite à maioria dessas aplicações correrem sem alterações. + +Quando uma aplicação é executada com o &artsdsp;, todos os acessos ao dispositivo de áudio /dev/dsp são interceptadas e mapeadas em chamadas à API do &arts;. Embora a emulação do dispositivo não seja perfeita, a maioria das aplicações funciona desta forma, ainda que com alguma latência e degradação de performance. + +O comando &artsdsp; segue o formato: + + +artsdsp [opções] argumentos da aplicação + +São reconhecidas as seguintes opções: + + + + +, + +Mostra uma breve ajuda. + + + + = nome + +Usa o nome para identificar o leitor no artsd. + + + + + + + +Emula o mapeamento de memória (⪚ para o Quake). + + + + + + +Mostra os parâmetros. + + + + + +Uma invocação típica é a seguinte: + + +artsdsp realplay musica.mp3 + + +Algumas aplicações funcionam melhor com a opção . Nem todas as funcionalidades do dispositivo de som estão emuladas por completo, mas a maioria das aplicações deverá funcionar. Se encontrar alguma que não funcione, envie um relatório de erro detalhado para que os programadores o possam corrigir. Mais uma vez, lembre-se que isto é uma solução intermédia e uma espécie de 'truque sujo'; a melhor solução será adicionar o suporte nativo do &arts; às aplicações. Se a sua aplicação de som favorita não tem o suporte do &arts;, peça ao programador para o fornecer. + + + + +<application +>artscat</application +> + +Este é um utilitário simples para enviar os dados em bruto para o servidor de som. Você precisa de indicar o formato dos dados (a taxa de amostragem, o tamanho da amostra e o número de canais). Este não é provavelmente um utilitário que use muito, mas poderá ser útil para fins de teste. A sintaxe do comando é a seguinte: + + + +artscat [ opções ] [ nome do ficheiro ] + +Se não for indicado nenhum ficheiro, irá ler do 'standard input'. São suportadas as seguintes opções: + + + + taxa de amostragem + +Configura a taxa de amostragem a ser usada. + + + + + bits + +Define o tamanho da amostra a usar (8 ou 16). + + + + + canais + +Define o número de canais (1 ou 2). + + + + + + +Mostra a utilização do comando e sai. + + + + + + + +&artscontrol; + +Este é um utilitário gráfico para efectuar um dado número de tarefas relacionadas com o servidor de som. A janela por omissão mostra dois indicadores do nível do volume e uma barra para controlar o volume global. No menu Ver, você poderá seleccionar outras funções: + + + + +Osciloscópio FFT + +Abre uma janela que mostra um visualização do tipo de analisador de espectro em tempo-real. + + + + +Gestor de Áudio + +Mostra as fontes de áudio activas e permite-lhe ligá-las a qualquer um dos barramentos disponíveis. + + + + +Estado do aRts + +Mostra se o servidor de som está a correr e se o escalonamento é feito em tempo-real. Indica quando o servidor se suspende automaticamente e permite-lhe suspendê-lo imediatamente. + + + + +Gestor de MIDI + +Mostra as entradas e saídas activas de &MIDI; e permite-lhe criar ligações [TODO: Isto ainda funciona? São precisos mais detalhes]. + + + + +FreeVerb + +Liga um efeito de reverberação FreeVerb à pilha dos efeitos de saída do &arts; e permite-lhe controlar graficamente os parâmetros do efeito. + + + + +Mostrador de volume com Leds + +Muda os indicadores de volume da janela principal para usar um mostrador colorido com LEDs em vez de usar barras de progresso. + + + + + + + + +<application +>artsc-config</application +> + +Este é um utilitário para ajudar os programadores a usar a API de C do &arts;. Ele mostra as opções apropriadas do compilador e do editor de ligações que são necessárias ao compilar e ao gerar um executável com o &arts;. Pretende-se que seja usado nas 'Makefile's para ajudar na portabilidade. O comando aceita três opções: + + + + + +Mostra as opções do compilador que são necessárias ao compilar com a API de C do &arts;. + + + + + + +Mostra as opções do editor de ligações que são necessárias ao gerar o executável que usa as bibliotecas da API de C do &arts;. + + + +--version + +Mostra a versão do comando artsc-config. + + + + +O resultado típico do comando é mostrado em baixo: + +% artsc-config +-I/usr/local/kde3/include/artsc +% artsc-config +-L/usr/local/kde3/lib -ldl -lartsc -DPIC -fPIC -lpthread +% artsc-config +0.9.5 + + +Você poderá usar este utilitário numa Makefile para uma regra do tipo: + +artsc: artsc.c + gcc `artsc-config --cflags` -o artsc artsc.c `artsc-config --libs` + + + + + +&mcopidl; + +O comando &mcopidl; é o compilador de ficheiros &IDL; para o &MCOP;, o 'Multimedia Communication Protocol' usado pelo &arts;. As interfaces no &arts; são definidas em &IDL;, uma 'Interface Definition Language' independente da linguagem. O utilitário &mcopidl; aceita um ficheiro &IDL; como entrada e gera ficheiros de inclusão e de código em C++ que implementam essa interface. O comando aceita a seguinte sintaxe: + + + +mcopidl [ opções ] nome do ficheiro + +As opções válidas são: + + + directoria + +Procura na directoria pelos ficheiros de inclusão. + + + + + nome + +Exclui a estrutura, interface ou tipo enumerado nome da geração de código. + + + + + + +Cria também os ficheiros .mcoptype/.mcopclass que contêm a informação do tipo para o ficheiro &IDL;. + + + + +Para mais informações sobre o &MCOP; e o &IDL;, poderá ver a secção Interfaces e &IDL;. + + + + -- cgit v1.2.1