DICCIONARIO FOTOGRÁFICO

DSLR ó Digital SLR

Se refiere a una camara de fotos digital REFLEX.

Macro
La relación de tamaños entre lo que vamos a fotografiar y el sensor(y por lo tanto la fotografía) .
En fotografias de cerca(varios centímetros) suele haber aumento y se relaciona de forma: fotografiado:fotografia, por lo que un macro 1:2 significa que duplica el tamaño.
Esta medida no suele darse en las cámaras convencionales.

No confundir con el zoom digital, que es capaz de modificar este parámetro.
Hay una relación macro para cada modo : teleobjetivo, granangular, modo macro.

Cuando se habla del aumento de 5x en teleobjetivo, estamos hablando de un macro 1:2, claro que nos tendrán que especificar si es con zoom incluido o no. (En las camaras comerciales lo incluirán, en las profesionales no lo incluirán).

Modo Macro
Se refiere a un modo de la máquina digital en el que se pueden realizar fotografias de muy cerca.
La medida mas interesante en el modo macro es la minima distancia focal, que puede ser incluso de un centímetro. Evidentemente, cuanto mas cerca estemos del objeto, con mas detalle tendremos la fotografía.

Modo Teleobjetivo.

Introducción a las MFC.

Traduccion del manual

La Biblioteca de Microsoft Foundation Class (MFC Library) es una libreria de clases C + + creada por microsoft con Microsoft Visual C + + para ayudar en el desarrollo de aplicaciones de Microsoft Windows. Aunque las MFC son sobre todo utilizadas en aplicaciones GUI, pueden ser utilizadas para desarrollar cualquier tipo de aplicación. La Biblioteca MFC consta de una serie de clases, que son ligeros 'envoltorios' de alto nivel para interfaces de programación de aplicaciones (API) como WinSock y ODBC. Todo el kernel Win32, GDI, y objetos de usuario se asocian a MFC clases.
A la librería MFC se le denomina biblioteca vertical, utiliza en gran medida la herencia de clase, y en pequeña escala las plantillas C + + .
La libreria MFC 1,0 fue publicada por primera vez en 1992 (con Microsoft C + + 7.0), cuando Microsoft cambió a 16 bits de Windows 3,1, y no contenía plantillas. La versión actual MFC 4,2 contiene clases basadas en plantillas. Usandose las MFC, las aplicaciones no tienen que modificarse mucho cuando se cambia entre diferentes plataformas. Por ejemplo, muchas aplicaciones MFC escritas para Windows 3.1 (Win16) pasan simplemente recompilado a plataformas Win32 tales Windows 95 y NT. Cuando salga Win64, no habrá que reescribir de nuevo las aplicaciones MFC.
Las librerías pueden cargarse dinámicamente o estáticamente. Espero que conozcas las diferencias entre una y otra opción.
Los siguientes capítulos tienen por objeto introducir a los laicos la programación de MFC. MFC aunque parece simple, requiere de uno a tener un fondo en Win32 y de programación C + +. Si no tienes ese fondo, estas notas no le ayudarán. Debido a la gran curva de aprendizaje para aprender Win32 y C + +, son muy pocos los programadores que dominan en el MFC. Toma un largo tiempo de estudio. Si lo que desea es escribir sencillas aplicaciones GUI, estudie VB en vez de MFC.

Hay muchos programadores de Visual Basic que desarrollan para windows. Cada día hay mas, sencillamente a través de cursos de 8 semanas VB. No se necesita mucha más experiencia que la que se requiere para hacer clic y arrastrar controloes a un formulario de Visual Basic. Esto se puede observar por los variados orígenes de los programadores de VB en el mercado. No se requiere una Licenciatura para escribir un simple programa de VB. Visual Basic sólo ofrece acceso a los recursos de windows que se utilizan en la mayoría de las aplicaciones. Por ejemplo, una barra de desplazamiento en Visual Basic es bastante simple. Pero, una barra de desplazamiento que cambia de color no se encontrará en Visual Basic. Si se necesita tener un control como este, tendrá que crear un control ActiveX , bien con C++ y Win32 puro y duro, o con la Bliblioteca de plantillas activas (ATL), o bien usando MFC. Para este problema, debido a su simplicidad, ATL sería el método más rápido y fiable de desarrollo. Después de que el control es construido, que puede ser utilizado por un programador de VB en sus forms. Muchos programadores de Windows que utilizan puro y duro Win32 API para desarrollar aplicaciones de ventanas han sido desplazados por los programadores de VB. Aunque C++ soporta Microsoft Visual Basic para el desarrollo de complicadas estructuras de datos, la sencilla interfaz de Visual Basic es preferida para el desarrollo.

Si se usa MFC para desarrollar una sencilla aplicación de Windows con elementos de la interfaz estándar, es probable tardar horas de desarrollo. En Visual Basic, se necesitaría sólo un par de minutos. MFC no destacaría, MFC no es para hacer esto. MFC destaca, cuando uno se enfrenta a una compleja aplicación con gran cantidad de programación Win32. Por ejemplo, tendrá que escribir una aplicación con múltiples hilos, sockets, y la base de datos de interacciones. Usted puede escribir su programa en C usando Win32 puro y duro , WinSock y ODBC. Pero este tipo de código es muy propenso a errores. (En Visual Basic , de una manera retorcida, puede declarar y llamar funciones de la api win32. El apoyo de Socket apoyo se puede lograr a través de controles especiales. Se pueden usar Bases de datos utilizando ADO. Sin embargo, estas aplicaciones VB tienden a ser inmantenibles). MFC sería la mejor apuesta para este tipo de aplicación.

Todas las clases MFC tienen la letra mayuscula C de prefijo. Por ejemplo, CString, CFile, CSocket, CMutex son classes de la librería MFC . Las clases MFC estandard son declaradas en afxwin.h. Si no usamos el asistente de creación de aplicaciones, tenemos que activar las MFC linkando las librerías estáticas o dinámicas de MFC. Todos los codigos de las siguientes páginas, usan Visual C++ 6.0.
Cada vez que usemos MFC en una aplicación de cónsola, necesitamos inicializar el soporte MFC run-time con la llamada a la función AfxWinInit. Si no nicializamos el MFC run time, El código puede terminar inesperadamente. Los siguientes capítulos muestran MFC bajo una perspectiva no GUI..

Declaración:	BOOL AFXAPI AfxWinInit( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow )
Información:	Función que inicializa el entorno run-time MFC. Retorno TRUE si es correcto.

El programa Box #1 demuestra un simple main que solo initializa el entorno runtime MFC.

// BOX #1: Initialize the MFC Runtime Environment. #include int main(void) { if(AfxWinInit(GetModuleHandle(NULL), NULL,GetCommandLine(),0)==FALSE) { cout<<"Unable to initialize MFC"<<endl; return 1; } /* Use MFC Classes Here !!! */ return 0; }

C++. Espacios de nombre

MIDI Formato de fichero. Eventos en tracks

Lo que he leido de los ficheros midis, me deja una duda que quiero solventar, por eso voy a traducir este documento.
Es una especie de borrador que espero ir arreglando.
Traducido de: aquí


Eventos en tracks.

Un MTrk(track) puede contener eventos MIDI y no eventos MIDI (es decir, los eventos que contienen datos como la configuración de tempo, los titulos, etc.)

Los primeros (1 a 4) byte (s) en un MTrk serán los delta-tiempos del el primer evento almacenados como una cantidad de longitud variable. El siguiente byte de datos es, en realidad, el primer byte de ese evento en sí. Voy a referirme a este byte como el Estado del Evento. Para eventos MIDI, ése será el byte de Estado MIDI (midi o el primer byte de datos en caso de running status). Por ejemplo, si el byte hexadecimal es 90, entonces este es un caso de Nota On en el canal midi 0. Si, por ejemplo, el byte hexadecimal es 23, lo que tenemos que recordar es el estado anterior (es decir, running status midi). Obviamente, el primer evento MIDI en la MTrk debe tener un byte de estado. Después de un byte de estado midi llegan sus bytes de datos 1 o 2 bytes de datos (dependiendo del Status - algunos mensajes MIDI sólo tienen despues 1 byte de datos ). Luego nos encontramso el delta-tiempo del siguiente evento (como una cantidad variable), etc

Eventos SYSEX

Eventos SYSEX (sistema exclusivo) (status = F0) son un caso especial porque un mensaje SYSEX puede ser cualquier longitud. Después del byte de Estado F0 (que siempre existe - no hay running-status aquí), encontrará una serie de bytes de longitud variable. De la misma forma que el delta-time pueden ser hasta 32 bits(8 bytes) que indica cuántos bytes más siguen al F0 y conforman el evento SYSEX. Esta longitud no incluye el Estado F0.

Por ejemplo, considere el siguiente mensaje SYSEX MIDI:

F0 7F 7F 04 01 7F 7F F7

Esto sería almacenado en un archivo MIDI con la siguiente serie de bytes (sin contar con los bytes de delta-tiempo que preceden al F0):

F0 07 7F 7F 04 01 7F 7F F7

La 07 es la cantidad de longitud variable (que pasa a caber en un solo byte para este ejemplo). Se indica que hay siete bytes despues del F0 para componer el mensaje SYSEX.

Los dispositivos midi del fabricante Really oddball envian un mensaje exclusivo del sistema(SYSEX) como una serie de "pequeños paquetes" (con un tiempo de retraso entre transmisión de cada paquete). La primera comienza con un paquete de F0, pero no termina con un F7. Los siguientes paquetes no empiezan con una F0 ,empiezan con F7 pero no finalizan con con F7. El último paquete no se inicia con una F0, se inicia con F7, pero sí termina con la F7. Así, entre el primer paquete de apertura de F0 y el último paquete de clausura del F7, hay un SYSEX mensaje. (Nota: sólo extremadamente pobres diseños, como el 'crap' comercializado por Casio exhiben tal horrible conducta). Por supuesto, como necesita una demora entre cada paquete, necesita almacenar cada paquete como un evento separado con su propio tiempo en el MTkr. Tambien, debe de alguna manera saber que eventos no deben comenzar con una F0 (es decir, todos ellos, excepto el primer paquete). Así, el archivo MIDI midi redefine una situación de F7 (que normalmente se utiliza como un fin para la marca SYSEX paquetes) como una forma de indicar que un evento no comienza con F0.
Si un evento sigue a un F0 evento, entonces se asume que el evento F7 es el segundo "paquete" de una serie. En este contexto, es mencionado como un caso SYSEX CONTINUACIÓN.
Al igual que el tipo de evento F0 , ls F7 tienen una cantidad de longitud variable seguida de bytes de datos.
Por otra parte, el evento F7 puede utilizarse para almacenar mensajes MIDI TIEMPO REAL o MIDI COMÚN(PERO NO MENSAJES DE CANAL). En este caso, después de los bytes de longitud variable, usted puede esperar encontrar un byte de Estado MIDI de F1, F2, F3, F6, F8, FA, FB, FC, o FE. (Tenga en cuenta que NO va a encontrar cualquiera de esos bytes dentro de un evento SYSEX CONTINUACIÓN). Cuando se usa de esta manera, el F7 evento es denominado ESCAPED evento.




Por lo que he entendio, un mensaje de SYSEX en formato continuación , son varios mensajes del formato.
F0datos
F7datos
.......
F7datos
F7F7


Otra cosa es el evento ESCAPE.
F7
En el evento ESCAPE caben los Estados comunes y Tiempo real.

Eventos no MIDI.
El estado de FF se reserva para indicar un evento especial no-MIDI.(Notar que FF es usado en MIDI con el significado de "reset", por lo que no es util almacenarlo en un fichero de datos. Sin embargo, el fichero MIDI redefine arbitrariamente el uso de este status). Despues del byte de estado FF, hay otro byte que nos indica el tipo del no-MIDI evento. Despues de este byte, tenemos otros bytes de cantidad de longitud variable que ya conocemos (ver delta-time). que nos indica la longitud del mensaje sin inccluir el FF el byte de tipo y la longitud misma. Estos no-MIDI eventos especiales se llaman Meta-Eventos, y la mayoría son opcionales mientras no se indique lo contrario. La seción de este libro online titulado "Meta-Eventos", lista los Meta-Eventos corrientemente definidos. Notar que aunque no ha sido mencionado, estos eventos se menten en un MTrk, puede haber mas de uno y llevan su delta-time correspondiente.(Como los eventos midi. Los Meta-Eventos tienen un delta-time que los separa del anterior evento. Tambien, puede libremente mezclar MIDI y Meta eventos).

MIDI Especificación. Mensajes excusivos.

Después de haber traducido la especificación de los mensajes midi, voy a traducir los que menos entiendo. los famosos mensajes exclusivos.
Traducido de aqúi


Mensajes Exclusivos del sistema (es decir, SysEx)

Propósito :
Se utilizan para enviar una gran cantidad de datos a un dispositivo MIDI, como un volcado de memoria de su patch(conjunto de instrumentos o datos del secuenciador o los datos de forma de onda(datos de audio). Asimismo, SysEx pueden ser utilizados para transmitir la información que es particular de un modelo de dispositivo. Por ejemplo, un mensaje SysEx podría ser usado para enviar la información del operador en un Sintetizador Roland de Modelado Físico. Esta información sería probablemente inútil para un sampler AKAI que reproduce muestras de sonido. (Por el contrario, prácticamente todos los dispositivos responden a un control de rueda de modulación, por ejemplo, así que tiene sentido tener definido un mensaje de controlador de modulación que todos los fabricantes puedan apoyar con ese fin).

Status:

Comienza con el byte de estado 0xF0. y termina con un byte de estado 0xF7 (es decir, después de los bytes de datos).

Datos:

Puede ser cualquier número de bytes de datos entre el 0xF0 inicial y el 0xF7 final. El más importante es el primer byte de datos (después del 0xF0), que debe ser una identificación del fabricante.

Errata ?????

Prácticamente todos los dispositivos MIDI definen el formato de su propio conjunto de mensajes SysEx (es decir, que sólo ellos lo entienden). El único punto en común de los mensajes SysEx de diversos modelos de dispositivos MIDI es que todos los mensajes SysEx debe comenzar con un estado 0xF0 y terminar con un estado 0xF7. En otras palabras, este es el único mensaje MIDI que tiene 2 bytes de estado, uno al inicio y otro al final.
Entre estos dos bytes de estado, cualquier número de bytes de datos (todos a cero el bit # 7, es decir, el valor de 0 a 127) puede ser enviado. Por eso necesita un SysEx 0xF7 estado byte al final, de modo que un dispositivo MIDI sabrá cuando el final del mensaje aparece, incluso si los datos del mensaje no es entendido por el dispositivo (es decir, el dispositivo no sabe Exactamente el número de bytes de datos a esperar antes del 0xF7).

Por lo general, el primer byte de datos (después del 0xF0) será un ID definido por el fabricante. La organización MMA ha asignado valores del byte ID a varios fabricantes, de manera que un dispositivo puede determinar si un mensaje SysEx se destina para el. Por ejemplo, un dispositivo de Roland espera un byte ID de 0x41. Si un dispositivo de Roland recibe un mensaje SysEx cuyo byte ID no es 0x41, el aparato hace caso omiso de todos los del resto de los bytes hasta que llega el byte final 0xF7 que indica que el mensaje SysEx ha terminado.

El objetivo de los restantes bytes de datos, que pueden ser muchos, son determinados por el fabricante . Normalmente, los fabricantes al ID del fabricante le sigue un byte de Número de identificación asi, un dispositivo no sólo puede determinar que hay un mensaje SysEx correcto del fabricante, sino también que es un mensaje SysEx específicamente para este modelo. Luego, después de la ID del modelo puede seguir otro byte que el dispositivo utiliza para determinar el tipo de mensaje SysEx , y, por lo tanto, el número de bytes de datos más que seguirán. Algunos fabricantes tienen un byte de checksum, (por lo general, justo antes de la 0xF7) que se utiliza para verificar la integridad de la transmisión del mensaje.
El byte de estado 0xF7 se utiliza para marcar el final de un mensaje SysEx. Nunca debe ocurrir sin precederle un Estado 0xF0. En el caso de que un dispositivo experimente tal condición (es decir, tal vez el cable MIDI se conectó a mitad de la transmisión de un mensaje SysEx), el dispositivo debe ignorar el Estado 0xF7.
Además, aunque el 0xF7 supone que marca el final de un mensaje SysEx, de hecho, cualquier byte de estado (a excepción de la categoría de mensajes en tiempo real), debe causar el mensaje SysEx como "terminado" (es decir, "abortado". Ya que tal situación indica una situación anormal del MIDI). Por ejemplo, si un 0x90 se envió después de un 0xF0 (pero antes de la 0xF7), entonces el mensaje SysEx se considera abortado en ese momento. Cabe señalar que, como todos los Mensajes Comunes del Sistema, SysEx anula cualquier 'runing status' actual. En otras palabras, el siguiente mensaje de Categoria de Voz (tras el mensaje SysEx) debe comenzar con un Estado.


Vaaaaya, creo que lo he entendio casi todo.
La unica duda que tengo es ese : (a excepción de la categoría de mensajes en tiempo real)

MIDI Especificación. Mensajes.

Primer post sobre el protocolo midi.
Esto es una tradución de aquí
Es una especie de borrador que dios 'menguante' trataré de formalizar.


Voy a tratar de ahondar todo lo posible desde mi experiencia.(¡ejem!.Que puede ser muy poca).

MENSAJES MIDI.

El protocolo MIDI está compuesto de mensajes. Un mensaje consiste en una cadena (es decir, serie) de bytes (de 8 bits). MIDI ha definido muchos de esos mensajes. Algunos mensajes constan de sólo 1 byte. Otros mensajes tienen 2 bytes. Otros tienen 3 bytes. Un tipo de mensaje MIDI puede tener un número ilimitado de bytes. Una cosa que todos los mensajes tienen en común es que el primer byte del mensaje es el byte de estado. Se trata de un byte especial porque es el único byte que tiene a 1 el bit #7. Cualquier otro byte del mensaje tiene el bit #7 a 0. Por lo tanto, siempre se puede detectar el comienzo un mensaje MIDI, ya que es cuando se recibe un byte con el bit # 7 a 1. El byte de estado estará entonces en el rango de 0x80 a 0xFF. El resto de bytes del mensaje (es decir, los bytes de datos, si existen) estarán en el rango 0x00 a 0x7F. (Tenga en cuenta que estoy usando el método que tiene el lenguaje de programación C para indicar un valor hexadecimal con el prefijo 0x.).

Los bytes de estado de 0x80 a 0xEF son para los mensajes que pueden ser difundidos en cualquiera de los 16 canales MIDI(en estos mensajes, hay que indicar a cual de los 16 canales afecta). Debido a esto, estos son llamados mensajes de voz. (Mi preferencia es decir, que estos mensajes pertenecen a la categoría de voz, algunos les llaman mensajes de canal.). Estos bytes de estado, hay que romperlos en dos nibbles de 4bits.Por ejemplo, un byte de estado 0x92 puede ser dividido en 2 nibbles con valores de 9 (nibble alto) y 2 (nibble bajo). El nible alto le indica qué tipo de mensaje MIDI es. Estos son los posibles valores del nibble alto, y qué tipo de mensaje de categoría voz(canal) representa cada uno:

• 8 = Note Off
• 9 = Note On
• A = AfterTouch (ie, key pressure)
• B = Control Change
• C = Program (patch) change
• D = Channel Pressure
• E = Pitch Wheel

Así, por ejemplo, nuestro byte de estado 0x92, corresponde a a un mensaje del tipo Nota On (es decir, el nibble alto es 9). ¿Cuál es el significado del nibble bajo 2 ?. Esto significa que el mensaje es para el canal MIDI 2. Hay 16 posibles (lógico) canales MIDI, siendo 0 el primero. Así que, este mensaje es una Nota On para el canal 2. ¿Qué byte de estado se especifica para un Cambio de Programa en el canal 0? El nibble alto para un cambio de programa es C, y el nibble bajo tendría que ser 0 para el canal 0. Así, la byte de estado sería 0xC0.¿Qué tal un Cambio de programa en el canal 15 (es decir, el último canal MIDI). Una vez más, el nibble alto es C, pero el nibble bajo es en este caso F (es decir, el digito 15 en hexadecimal ). Así, el byte de estado sería 0xCF.
NOTA: Aunque el byte de estado MIDI cuenta con los 16 canales MIDI, como los números de 0 a F (es decir, de 0 a 15), todos los aparatos MIDI (incluyendo los programas informáticos) muestra un número de canal para el músico como del 1 al 16. Así, un byte de Estado enviado al canal MIDI 0 se considera el "canal 1" en la medida de lo es el músico en cuestión. Esta discrepancia entre el número de canal del byte de estado , y el canal MIDI al que el músico "cree" mandar el mensaje, se acepta porque la mayoría de los seres humanos empieza a contar las cosas a partir del 1 , en lugar de 0.

Los bytes de estado de 0xF0 a 0xFF, son para los mensajes que no están asociados a ningún canal (y por lo tanto todos dispositivos MIDI(en el sentido de dispositivos que respondena sólo un determinado canal) siempre pueden "escuchar" y optar por actuar con respecto a estos mensajes. Esto contrasta con la categoría de mensajes de voz, que solo actuan en un dispositivo MIDI configurado para responder a los mensajes de un determinado canal cuando coincide el número de canal del mensaje y el del dispositivo.). Estos bytes estado(0xF0 a 0xFF) se utilizan para los mensajes que llevan la información de interés para todos los dispositivos MIDI, como por ejemplo el sincronizado de todos los dispositivos de reproducción a un momento determinado. (Por el contrario, los mensajes de categoría de voz se refieren a las partes de musica individual que podrían desempeñar cada uno de los instrumentos, por lo que el esquema del nibble de canal permite a los dispositvos responder a su propio canal MIDI haciendo caso omiso de los mensajes de categoría voz destinados a otro dispositivo en otro canal).

Estos bytes estado(0xF0 a 0xFF) se dividen en dos categorías. Los Mensajes con bytes de estado de 0xF0 a 0xF7 son llamados mensajes comunes del sistema. Los mensajes con bytes de estado de 0xF8 a 0xFF son llamados mensajes en tiempo real del sistema. Las implicaciones de estos tipos se discutirám más adelante.

En realidad, algunos bytes de estado dentro de este rango(0xF0 a 0xF7) no están definidos por la especificación MIDI a la fecha, y se reservan para uso futuro. Por ejemplo, los bytes de estado 0xF4, 0xF5, 0xF9, y 0xFD no se utilizan. Si un dispositivo MIDI recibe dichos bytes de estado, debería ignorar el mensaje. Véase la sección: Ignorando mensajes MIDI.

Lo siguiente sería una descripción de cada tipo de mensaje. La descripción de lo que el mensaje significa, lo que significa su byte de estado, y si tiene algún posteriores bytes de datos y el tipo de información que llevan. En general, estas descripciones dependen de lo que haga dispositivo de recibir dichos mensajes (es decir, lo que esperamos que el dispositivo haga al recibir el mensajes). En su caso, tambien puede haber comentarios acerca de los dispositivos que transmiten estos mensajes.

------------------------
La especificación general de los mensajes esta super bien explicada. Otra cosa es verlo en la práctica.

firmas gpg

Breve comentario de la necesidad de firmas y como hacerlo con gpg

Pregunta:
Para que sirve firmar un documento:
Respuesta:
1.- Para que el que lo lea sepa quien lo ha escrito.
2.- Para que sepamos que el documento es original.


Pregunta ¿Como firmamos con gpg?

Respuesta:
Una vez creada nuestra clave, podemos firmar el fichero con este comando:
gpg --output ficherofirmado.sig --sign fichero

Pregunta:¿Como verifico que es correcto el fichero firmado y quien lo ha firmado?
Respuesta:
gpg --verify ficherofirmado.sig

Pregunta: ¿Como recuperamos el fichero firmado con gpg?
Respuesta:
gpg --output fichero --decrypt ficherofirmado.sig
No nos pedirá ningun password ni 'nada' y nos dirá quien lo ha firmado.


Pregunta:¿Pero yo tengo un fichero de texto y quiero que se conserve el texto y se vea la firma?
Respuesta:
gpg --outpt ficherofirmado.asc --clearsig fichero
Pregunta:¿Y como verifico el fichero firmado en texto?
Respuesta:
Pues igual : gpg --verify ficherofirmado.asc
Pregunta:¿Y si quiero conservar el fichero original y la firma que esté en un fichero separado?
Respuesta:
También se puede de esta forma:
$ gpg --output firmadefichero.sig --detach-sig fichero
el fichero se queda como esta y se genenera uno nuevo firmadefichero.sig
Pregunta: ¿En este caso como verifico la firma?
Respuesta:
gpg --verify firmadefichero.sig fichero