PowerFl Compile Process Presentation
파워플 솔루션이 어떠한 방식으로 컴파일을 진행하는지 간단히 아키텍쳐를 생각해봤습니다.
화면을 클릭하시면 진행됩니다. 이번에도 저번 처럼 pt소스를 공개합니다.
Archive for April 2010
Sound 사용하지 않기 – 2
Sound객체의 문제를 해결하기 위해서는 역시 Sound객체를 사용하지 않는 편이 좋습니다. Sound객체는 AVM2가 OS의 사운드드라이버와 통신하는 부분을 래핑하여 개발자에게 제공해주는 API로 이해할 수 있습니다. 하지만 이러한 OS의 사운드드라이버와 연결되는 API객체가 하나 더 있습니다. 바로 NetStream객체입니다. 따라서 Sound객체를 버리고 NetStream으로 이행하여 소리에 관련된 처리를 하는 솔루션을 생각해볼 수 있습니다.
여기에는 선행조건이 있습니다. mp3가 아닌 mp4포멧으로 정의된 음악파일을 사용한다는 점이죠. 따라서 유저가 업로드하거나 이미 구축된 mp3를 플레이하는 스타일의 어플리케이션에서는 활용이 제한됩니다. 또한 사운드 스펙트럼이나 동적인 사운드 필터효과 등을 주는 것도 Sound객체 고유의 능력이라 NetStream으로는 구현할 수 없습니다.
반대로 생각해보죠. 일반적으로 제작되는 swf의 배경음악, 효과음악 등은 결국 개발회사의 통제권 하에 있습니다. 서버에 mp3를 올릴 생각이라면 mp4로 올린다고 뭐가 어떻게 되는건 아니겠죠 ^^;
오디오를 위한 mp4
제가 이 글에서 구체적인 코덱과 스트림파일에 대한 개괄적인 내용은 다루지 않겠습니다만 개념적인 이해를 돕기 위해 간단히 정리를 해보겠습니다. 일단 mp4, avi 등의 형식은 쉽게 인식하자면 하나의 껍데기로 생각할 수 있습니다. 그 안에 실제 내용물인 영상이나 소리가 들어갈 때는 여러 가지 코덱을 따로 고를 수 있습니다. 따라서 같은 mp4사운드라 할지라도 aac나 aacPlus 등의 상이한 코덱을 사용할 수 있다는 겁니다.
최근에야 m4x시리즈로 바뀌긴 했지만 구세대 아이팟을 사용해오셨다면 애플은 오래 전부터 mp4를 음악파일로 사용해 왔다는 것을 아실 겁니다. 휴대폰에서 일반적으로 발견되는 k3g등의 포멧은 실상은 전부 mp4로 이미 mp4는 사운드 파일로서 광범위하게 사용되고 있습니다.
mp4의 장점은 크게 두 가지 입니다.
- 같은 품질의 mp3에 비해 현격하게 작은 용량
- 원하는 위치로 점프(seek)할 때 훨씬 빠르게 작동함
2번과 관련된 문서가 웹에는 많습니다. mp4 seek 이나 mp3 seek 정도로 검색하시면 쏟아질 겁니다.
Sound 사용하지 않기 – 1
Sound는 매우 난해하고 어려운 객체입니다. 하지만 동시에 거의 모든 프로젝트에서 소리 자체는 사용해야만 합니다. 따라서 거의 두 가지 형태로 사용하게 됩니다.
- 외부 사운드 편집툴에서 충분히 소리를 만진 뒤 플래시에서는 최대한 간단히 Sound객체를 사용한다.
- 심각하게 Sound객체를 사용하여 소리를 처리한다.
결과적으로 전 두 가지 경우 다 좋지 않다는 결론에 이르렀습니다. Sound객체는 수 많은 문제점을 안고 있기 때문에 엄청난 추상층이 필요합니다. 이러한 추상층에서의 구현은 단단한 하부 API와 거리가 있기 때문에 잦은 타이밍 오류나 문제점을 발생시킵니다. 그래서 어떻게 하면 소리를 처리하는데 있어 Sound객체와 멀어질 수 있을까 알아보기로 하겠습니다.
PowerFl Kickoff Presentation
파워플 솔루션이 어떠한 방식으로 컴파일을 진행하는지 간단히 아키텍쳐를 생각해봤습니다. 화면을 클릭하시면 진행됩니다.
재밌는 사실 있습니다. 이 PT화면을 만드는데 고작 아래와 같은 코드밖에 필요치 않습니다.
Removing compiler problem markers
오랜만에 올려보는 이클립스 쿡북시리즈입니다.
이 에러가 왜 생기는지는 중요치 않습니다. 쨌든 이 에러를 언젠가는 만나게 됩니다 ^^ 에러가 생기는 시점은 Problems창에 에러가 뜬 뒤 문제를 해결하고 그 이 에러를 이클립스가 지우려고 했으나 지울 수 없을 때 생기는 에러입니다. 이클립스를 재시동해도 소용없습니다.
해서 검색해보면 가장 흔하게 올라오는 해결책이 프로젝트를 지우고 다시 만들어라 입니다만, 그런 위험한 짓을 할 수 없습니다. 그래서 문제창을 더 자세히 보면
An internal error occurred during “Removing compiler problem markers”.
java.lang.NullPointerException
이런 메세지를 만나게 됩니다. 이거야 말로 자바가 마커를 지울라고 했더니 널포인트 에러를 당해서 지우지 못했다는 거 아니겠습니까.
그럼 곰곰히 생각해 볼 차례입니다.
- 이클립스는 이 에러 마커를 어디에 기록해 둘까?
- 그 기록하는 곳에 에러가 해결되어 마커를 지우려니 에러가 생긴게 아닐까?
- 그럼 그 마커를 직접 내가 지워주면 되는거 아닐까?
이러한 방법으로 접근해보면 손쉽게 해결할 수 있습니다.
- 이클립스는 해당 프로젝트의 마커를 다음과 같은 경로에 지정합니다.
- <workspace>/.metadata/.plugins/org.eclipse.core.resources/project/프로젝트명/.markes
- 따라서 먼저 이클립스와의 충돌을 피하기 위해 이클립스를 종료하고 저 위치에 있는 .markes 파일을 지워버립니다.
- 다시 이클립스 구동하면 문제는 해결되어 있습니다.
그나저나 플래시빌더 짜증이 밀려오네요. 3배이상 느려진 컴파일 타임, 잦은 오류 및 다운, source path로 잡아준 라이브러리클래스를 직접 찾아가지 못하고 반드시 대상 라이브러리 프로젝트를 열어야 찾아가는 점 등 열거할 수 없이 불편한 점이 산재하여 플렉스빌더로 돌아갈까 말까 고민하고 있습니다.
