Guia de produção técnica
Rider técnico: o que incluir e como mantê-lo útil
Um bom rider técnico não é uma lista de desejos: é um acordo operacional que reduz dúvidas antes do load-in. Este guia ajuda músicos, técnicos e produção a preparar um documento claro, atual e fácil de confirmar com cada venue.
O essencial
- Identifica espetáculo, versão, contacto técnico e âmbito logo na primeira página.
- Separa requisitos essenciais de preferências e alternativas aceitáveis.
- Inclui input list, patch, palco, energia, horários e responsabilidades.
- Fecha o advance por escrito e guarda a versão aprovada junto da data.
O que é um rider técnico — e o que não é
O rider técnico descreve as condições necessárias para montar, operar e desmontar um espetáculo. Deve permitir que venue, promotor, fornecedor e equipa visitante compreendam o mesmo plano antes de o material chegar ao cais.
Não substitui uma conversa de advance, um contrato ou uma avaliação local de segurança. Também não deve misturar informação técnica com hospitalidade sem uma separação clara: quem prepara áudio precisa de encontrar o patch sem percorrer páginas sobre camarins e catering.
- Rider técnico: áudio, luz, vídeo, palco, energia, rigging, comunicações e equipa.
- Stage plot: posição física de músicos, instrumentos, monitores, energia e linhas.
- Input list: canais, fontes, microfones/DI, inserts, suportes e observações.
- Rider de hospitalidade: transportes, alojamento, camarins, refeições e outras condições não técnicas.
Estrutura recomendada para um rider técnico
A ordem deve acompanhar a forma como a produção trabalha. Começa por identificação e contactos, apresenta o resumo do espetáculo e só depois entra no detalhe por departamento. Usa títulos consistentes e numeração de páginas; ficheiros com nomes como rider-final-v2-novo.pdf são uma fonte previsível de erros.
1. Identificação e controlo de versão
Artista ou projeto, nome do espetáculo, data da revisão, número da versão e contacto técnico com telefone e email.
2. Resumo operacional
Duração, número de pessoas em palco, equipa visitante, formato de viagem e requisitos que podem inviabilizar o espetáculo.
3. Áudio
Sistema, cobertura, consola, stagebox, input list, outputs, monitores, RF, talkback, gravação e formatos de sessão.
4. Palco, energia, luz e vídeo
Dimensões úteis, praticáveis, distribuição elétrica, posições, universos, superfícies de vídeo, rigging e limitações de peso.
5. Horários e responsabilidades
Acesso, load-in, montagem, line check, soundcheck, portas, show e load-out, indicando o que fornece cada parte.
Como escrever requisitos sem bloquear a produção
Distingue sempre entre obrigatório, preferencial e equivalente aceite. Uma referência de equipamento pode comunicar uma função, mas uma lista de marcas sem contexto obriga a trocas de email desnecessárias. Explica capacidade, ligações, quantidade e resultado esperado.
Quando não existe alternativa segura ou artística, escreve a razão e pede confirmação explícita. Quando existe, define-a: por exemplo, uma consola com número mínimo de inputs, buses, matrizes e compatibilidade com o ficheiro de sessão.
Do envio ao advance fechado
Enviar o PDF não significa que o rider foi aceite. O fecho acontece quando alguém com responsabilidade confirma o plano, identifica desvios e atribui ações com prazo. Em datas pequenas, um email estruturado pode ser suficiente; em operações maiores, usa uma chamada e envia o resumo logo depois.
- Confirma quem é o contacto técnico local e quem decide alterações.
- Regista cada desvio: item pedido, solução proposta, responsável e prazo.
- Anexa stage plot e input list na mesma versão, ou liga-os por um identificador comum.
- Distribui apenas a versão aprovada e arquiva as anteriores sem as deixar na pasta ativa.
- Associa o documento ao gig certo para evitar usar o rider de outra formação ou tour.
Erros que criam problemas no dia
Os piores erros raramente são tipográficos. São ambiguidades operacionais: canais sem fonte, desenhos sem escala, necessidades de energia sem potência, ficheiros sem versão, contactos desatualizados ou equipamentos pedidos sem indicar a função que cumprem.
- Copiar o rider da tour anterior sem rever formação, repertório e equipa.
- Misturar necessidades essenciais e preferências na mesma lista.
- Omitir o que a equipa visitante transporta e o que espera encontrar.
- Não prever tempo para descarga, montagem, teste, afinação e troubleshooting.
- Guardar a confirmação final num canal a que parte da equipa não tem acesso.
Modelo prático
Modelo base de rider técnico
Copia esta estrutura para o teu documento e elimina as secções que não se aplicam. Um rider curto e completo é melhor do que um ficheiro longo com campos vazios.
RIDER TÉCNICO — [ARTISTA / ESPETÁCULO] Versão: [AAAA-MM-DD / V1] Contacto técnico: [NOME · TELEFONE · EMAIL] 1. RESUMO - Formação em palco: - Equipa visitante: - Duração do espetáculo: - Requisitos essenciais: 2. HORÁRIOS - Acesso / load-in: - Montagem: - Line check / soundcheck: - Portas / show: - Load-out: 3. ÁUDIO - PA e cobertura: - FOH / monitores: - Input list e patch: - Microfones, DI, RF e stands: - Comunicações / gravação: 4. PALCO E ENERGIA - Dimensões e praticáveis: - Stage plot: - Pontos e distribuição elétrica: - Backline fornecido / transportado: 5. LUZ, VÍDEO E RIGGING - Sistema e controlo: - Posições / universos / conteúdos: - Pontos de rigging e cargas: 6. EQUIPA E RESPONSABILIDADES - Equipa local necessária: - Material fornecido pelo promotor: - Material transportado pelo artista: 7. DESVIOS APROVADOS - Item · solução · responsável · data de confirmação
Perguntas frequentes
Qual deve ser o tamanho de um rider técnico?
O necessário para executar o espetáculo sem ambiguidades. Uma atuação simples pode ficar clara em poucas páginas; uma produção com vários departamentos precisa de anexos. A prioridade é encontrar informação depressa, não atingir um número de páginas.
O rider técnico deve incluir marcas e modelos?
Pode incluir referências quando são relevantes, mas deve explicar a capacidade ou função exigida e indicar equivalentes aceitáveis sempre que possível.
Com que frequência deve ser atualizado?
Sempre que mudam formação, repertório, patch, backline, equipa ou necessidades de produção. Mesmo sem alterações, confirma contactos e versão antes de uma nova série de datas.