Holic Spirit :: Tistory Edition

musescore으로 debussy-toccata를 그려보자 #1

frontjang — Wed, 22 Feb 2012 13:54:58 +0900

지난주부터 Debussy의 pour le piano 수록곡인 toccata를 연습하기 시작했다. 연습하다보니 기존 악보에 있는 운지법이 맘에 들지 않아 PDF 판을 편집해서 운지법만 수정하려 했으나, 하다보니 새로 악보를 그리고 싶은 마음이 들어 작업을 시작한지 며칠이 지났다. finale, noteworthy composer등의 쟁쟁한 악보 제작 프로그램을 사용해왔지만 무료프로그램을 사용해보고 싶기도 했기 때문에 찾다가 musescore로 작업을 해왔다. 물론 최강자인 lilypond가 있지만 여기에서까지 '언어'를 사용하고 싶진 않았다..

현재는 음계는 다 입력해서 완전한 연주가 가능하지만(13장짜리 악보를 6장으로 줄여버렸다!), 기존 악보에서 셈여림, 지시사항 및 악보 표기등을 적용해야 하는 단계가 남아있다. (운지법은 아직 꿈도못꾸고있다 악보 하나 만드는것이 이렇게 큰일인줄 몰랐다. 흑흑) 아무튼 이번에 악보를 만들면서 알게 된 사항들을 하나하나 정리해 보려고 한다. 우선 첫 마디부터 문제에 봉착했고, 이 대응방법을 공개한다.

[그림 1] 원본과 작업본, 작업본을 확대하면 흔적이 보인다.

위의 그림을 보면 알겠지만 서로 같은 오선상의 8분음표등은 자동으로 4개씩 잘 엮인다. 하지만 다른 오선에 위치한 경우 서로를 전혀 다른 시스템으로 인지하고 서로 엮어줄 생각을 전혀 하지 않는다. 비슷한 경우로 공식 홈페이지에 문서(How to span a stem on two staves)가 있지만 이 예를 이번 경우에 적용시키려면 약간의 트릭이 필요하다. 여기에서는 성부(Voice) 기능을 사용하였다.

[그림 2] 성부기능과 비표시설정을 사용한 예

[그림 2]는 두개의 화면을 보기좋게 하나로 이어 저장한 것이다. 우선 파란색과 초록색이 있는데 각각 성부 1, 성부 2로 되어있다. 악보를 그릴때 기본으로 성부 1으로 지정되어 그려지며, 다른 성부를 사용하기 위해서는 그림 상단에 보이는 색깔로 칠해진 1234에서 원하는 성부를 누르면 된다. 포토샵을 해본 사람이라면 Layer를 생각하면 편하다. 즉, 서로가 전혀 분리된 시스템을 갖는다는 것이다.

성부 1의 5번째(미#) 동그라미와 막대를 각각 클릭하여 강조되게 한 후 오른쪽 버튼을 누르면 나오는 메뉴 중 '비표시 설정'을 누르면 오른쪽과같이 회색으로 변하면서 출력 결과에는 표시되지 않게 된다. 성부 2에서는 4분쉼표를 입력 후 4분음표를 입력하는 방식을 사용하였다. 단, 레#만 입력시에는 막대가 이어지지 않으므로 미 를 삽입하여 막대가 서로의 가운데에 위치하게 하는 꼼수를 사용한다. 그리고 막대부분을 더블클릭하여 크기를 늘려준다. 또한 8분음표의 줄무늬 부분을 더블클릭하여 나오는 두개의 점을 사용하여 위치(왼쪽버튼, 아래로 얼마나 더 위치할것인가를 결정)와 각도(오른쪽 버튼, 왼쪽 부분은 가만히 있고 오른쪽 부분의 높낮이를 결정한다)를 조절한다. 말로하려니 힘이들어 (이해하시긴 더욱 힘들듯하여) 동영상을 제작하였다!

문제라면 [그림 1]에서와 같이 약간의 틈이 존재한다는것. 아마 감춰진 음계에 막대가 연결되는것으로 인지하기 떄문인것 같은데그래도 흉내라도 냈으니 만족한다!

테가솝 틴 시리즈(원형, 사각형) 비교하기

frontjang — Mon, 13 Feb 2012 12:26:18 +0900

[그림 1, 2] 테가솝 원형(보라색, 50043), 사각형(파란색, 50010) 시리즈

이 사용기는 테가솝 자체의 효능보다는 원형과 사각형 시리즈의 질과 양적 측면을 비교하는 게시물입니다.

여드름이 한번에 확 나는것이 아니라 귀찮게 하나둘이 지속적으로 난다. 이건 각종 트러블용 제품을 써봐도 그다지 개선이 되는것 같지는 않다. 확산을 방지해주는 느낌으로 사용하고 있으며. 안고 살아야 할 동반자라고 생각하고 있다. 사실 식습관과 수면습관을 바꾸는것이 확실한 개선책임을 몸으로 느끼긴 했다 하지만 알아도 실천을 못하는 현실, 어쩔 수 없이 가끔 생기는 여드름을 짜기로 한다. 간혹 스팟용 제품을 써봐도 '일어나보니 없어졌어요'같은 마술은 일어나지 않았기 때문이다.

여드름을 짠 흉터가 남길래 이를 방지하고자 제품을 찾던 중 듀어덤이니 이지덤이니 등등이 있었지만 가장 평이 많고 좋았던 테가솝을 쓰기로 했다. 테가솝 틴이라고 하길래 10대용으로 생각했었는데 얇다는 Thin이 틴으로 된것, 사실 한글로 쓰려면 가장 적절한 것 같다 아니면 씐이라고 적어야 하나? 더욱 이상하군! 아무튼 처음 원형과 사각형이 있다는것을 알고는 원형을 사용했다. 사용기에, 사각형을 사용하면 자르는 번거로움도 있고 위생상으로도 문제가 있을 수 있다고 했기 떄문이다.

하지만 원형시리즈의 경우는, 각 개체?사이의 공간이 은근히 넓어서 몇번 쓰다보면 어느새 다 쓰게 되는 단점이 있었다. 참고로,개체의 크기가 3개로 나뉘어져 있는데-아래 그림 참고, 여드름의 흉터 사용에 있어서, 가장 큰 개체는 너무 커서 공간낭비가 있고, 가장 작은 개체는 짜고도 볼록 튀어나온 반동종자를 다스리기 어렵다. 큰 개체는(위에 두줄) 갯수도 별로 없어서 다루기 어려운 보스몹을 상대하기에 적당하고, 중간사이즈(아래 두줄)는 평소에 사용, 가장 작은 개체(가장 아래 세줄)는 외출시에 잘 보이지 않는곳에 쓰면 좋다.

[그림 3, 4] 사각형(파란색, 50010) 시리즈 10개들입, 원형(50043)과 사각형(50010) 시리즈의 크기?용량? 비교

따라서 어짜피 여드름을 평생 달고 산다고 가정하고 용량이 더 많아보이는, 사각형 시리즈 10개들입을 한번에 사기로 했다.[그림 3] 너무도 많다.. 박스 하나에 10개가 들어있는데(대개 박스 1개에 2-3개 정도 들어있음) 펼쳐보니 마치 테가솝 부자가 된 느낌이었다. 혹시 몰라 기존 원형 시리즈와 크기를 대조해 보았는데[그림 4] 이걸 보고 무조건 사각형 시리즈를 사야한다고 생각되었다. 크기 자체가 차이 날 뿐만 아니라 원형 시리즈에 있던 개체간의 공간이 없다!

그럼 이 사각형 시리즈를 어떻게 사용할 것인가? 적당한 높이를 생각한 후 깨끗한 커터칼로 슥슥 잘라서(바닥에 종이 여러겹을 깔고 하면 좋다) 칼국수를 만들어 버린다. 가위로 하려고 하면 가위 날과 콜로이드 부분이 접착이 되어 잘 잘라지지 않기 떄문이다. 그 후 미용가위로 역시 적당한 사이즈로 잘게 잘라준다. 그리고 나서 락앤락 용기에 담아서 사용하고 있다. 한 사 각형 면에 적어도 100개의 개체를 만들 수 있기 떄문에 한번 잘라두면 두고두고 사용할 수 있다. 또한 크기도 마음대로 하여 자를 수 있어서 적합한 위치에 적합한 크기를 붙일 수 있어서 좋다.

단 내가 산 제품만 그런지는 모르겠는데 마치 물에 젖은거마냥 각개 포장이 쭈글쭈글했다. 그리고 내부에 테가솝의 공기면을 차단하는 코팅종이가 있는데(코팅종이|테가솝|비닐코팅 이렇게 보호되어있다) 이것 역시 너무나 쉽게 떼어졌다. 칼로 자르는 도중에도 저절로 떼어지기도 했지만, 코팅종이 부분은 실제로 작용하는 부분은 아니니 넘어가도 될것같다.. 그리고 실제로 원형 테가솝보다 접착력이 떨어졌다. 원형은 세수를 해도 떨어지지 않았었는데 사각형은 막 포장을 뜯고 붙였음에도 불구하고 몇번 세게 문지르면 떨어졌다. 따라서 접착력이 강한것을 원한다면 원형, 아닌 경우에는 사각형을 사용하고 있다.

직접 자른 사각형 테가솝 개체는 외부로 나가서 사용하기는 모양이 없어보이므로 이때 간간히 원형 테가솝을 사용하여 그나마 외관을 신경써준다. 단 어떤것을 쓰든지 남들에게 보이긴 한다. 그리고 테가솝이 상처부위를 치유하는 도중 색깔이 하얗거나 노랗게 변하는데 이떄는 더욱 눈에 띄게 된다. 이 위에 비비를 발라볼까?

P/Invoke로 다이얼로그 창 제어하기 #3. DLL 만들고 외부 프로세스와 연결하기

frontjang — Sun, 12 Feb 2012 10:05:35 +0900

지난글(P/Invoke로 다이얼로그 창 제어하기 #2. SetWindowsHookEx() 소개)에 이어지는 글입니다. 특히 기존에 있었던 c#코드(P/Invoke로 다이얼로그 창 제어하기 #1. 현재 프로세스 제어)를 c++로 포팅하는데 게시물의 목적이 있습니다. 막상 변환하던 도중 다이얼로그 창을 제어할 다른 우회방법을 발견하여 막상 계획했던 장기 연재 프로젝트를 여기에서 중단해야 할것 같습니다. 아무튼 개략적인 설명은 다음과 같습니다. 이 프로젝트는 다이얼로그 창을 닫는데에 목적이 있다 하겠습니다. 만약 다이얼로그 창의 내용을 불러와서 그 내용에 맞게 처리하는 로직을 생각했었더라면 코드가 조금 더 복잡해 졌을것입니다.

DLL을 호출하는 프로그램(서버)와 DLL(드라이버)로 나누어 생각해 본다면, 서버에서는 드라이버를 다른 프로세스에 부착하는 역할을 수행하고, 드라이버 측에서는 부착된 프로세스에서 발생하는 메시지를 읽어서 해당 프로세스에 확인 버튼을 눌렀다는 메시지를 전송하는 역할을 하며, 그리고 후킹을 종료할 경우에는 서버에서 드라이버를 제거하는 구조로 되어있습니다. 참고로 후자의 경우(통신기능)일 경우에는 서버와 드라이버가 분리되어 있기 떄문에 드라이버 측에서는 서버의 위치와, 그리고 서버상에 등록되어있는 콜백함수를 이어주는 포인터등을 가지고 있어야 합니다(혹은 드라이버가 수집한 메시지를 서버에게만 전달하는 방법을 사용할 수 있겠습니다)

현재 서버는 c#으로 작성되어 있으므로 다음과 같이 설정해 줍니다. 소스는 여기(SetWindowsHookEx doesn't work with thread Id)에서 가져왔습니다 LIBRARY에는 드라이버명, PROC에는 프로시저명(DialogProc)을 기입하며, threadId는 GetWindowThreadProcessId()등을 사용하면 될것입니다. 게시물에는 답변대로 안될 이유가 없어서 그냥 가져왔습니다 (지금 게시물은 구현이 안된 상태에서 작성하는 것입니다)

[DllImport( "user32.dll", SetLastError = true )]
static extern IntPtr SetWindowsHookEx ( int hookType, UIntPtr lpfn, IntPtr hMod, uint dwThreadId );

[DllImport( "kernel32", CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = true )]
public static extern UIntPtr GetProcAddress ( IntPtr hModule, string procName );

[DllImport( "kernel32", SetLastError = true, CharSet = CharSet.Unicode )]
public static extern IntPtr LoadLibrary ( string libraryName );

const int WH_CBT = 5;

void SetHook (){
    IntPtr dll = LoadLibrary( LIBRARY );
    UIntPtr proc = GetProcAddress( dll, PROC );
    uint threadId = GetAppWindowThreadId();
    IntPtr hookAddress = SetWindowsHookEx( WH_CBT , proc, dll, threadId );
}

c++로 작성된 드라이버의 메시지 처리부는 다음과 같습니다. 1번 게시물과 비교하시며 보시면 좋을 것 같습니다. 이외 DLL제작에 있어 생략된 부분(DllMain 등)이 있으나 채우는데 어려움이 없으실거라 생각됩니다. 또한 CallNextHookEx()에서의 첫번째 인자는 무시되므로 그냥 NULL으로 처리하였습니다.

list<HWND> lstChildWindows;
void listChildWindows(HWND p){
    EnumChildWindows(p, EnumChildProc, 0);
}

BOOL CALLBACK EnumChildProc( HWND hwnd, LPARAM lParam ){
    lstChildWindows.push_back(hwnd);
    return TRUE;
}

LRESULT CALLBACK DialogProc(int nCode, WPARAM wParam, LPARAM lPARAM){
    CWPRETSTRUCT * cwpretStruct = (CWPRETSTRUCT*)lPARAM;

    if(nCode>=0){
        if ( ( cwpretStruct->message == WM_INITDIALOG )){
            HWND pOkButtonHwnd=NULL;
            int iLength=GetWindowTextLength(cwpretStruct->hwnd);
            TCHAR* sb= new TCHAR[iLength];
           GetWindowText(cwpretStruct->hwnd, sb, iLength);
            listChildWindows(cwpretStruct->hwnd);

            list<HWND>::iterator i;
            for(i=lstChildWindows.begin(); i != lstChildWindows.end(); ++i) {
                TCHAR* sbProbe= new TCHAR[100];
                if(GetClassName(*i, sbProbe, 100) !=0 && _tcslen(sbProbe) >0){
                    if(_tcscmp(sbProbe, _T("Button"))==0){
                        iLength=GetWindowTextLength(*i);
                        if(iLength>0){
                            TCHAR* sbText=new TCHAR[iLength];
                            GetWindowText(*i, sbText, iLength);
                            if(_tcscmp(sbText, _T("확인"))==0) pOkButtonHwnd=*i;
                            delete sbText;
                        }
                    }
                }
                delete sbProbe;
            }

            if(pOkButtonHwnd!=NULL){
                int ctrlId=GetDlgCtrlID(pOkButtonHwnd);
                SendMessage(cwpretStruct->hwnd, WM_COMMAND, (WPARAM)ctrlId, (LPARAM)pOkButtonHwnd);
                return 1;
           }
       }
    }
    return CallNextHookEx(NULL, nCode, pWParam, pLParam);
}

사실 다이얼로그 창을 제어하기 위한 까닭은 개인적으로 사용할 인터넷 Automation을 툴을 만드는 중, alert창등이 뜨면 이것에 막혀서 COM객체를 사용할 시 오류가 나게 되기 때문에 이를 억제하기 위함이었으며, 물론 windows.alert={}등으로 처리할 수도 있겠지만 이것을 적용하기 힘든 구조였기 때문에 좀 더 확실한 방법을 찾고자 후킹을 사용한 다이얼로그 제어를 생각하게 된것입니다. 그러다 떠오른것이 '다른 프로젝트를 검색해보는것은 어떨까?'였으며 만족스럽진 않지만 결과를 얻어 사용중입니다. 다음에는 자동화 툴 커스터마이징에 대해 알아보겠습니다.

P/Invoke로 다이얼로그 창 제어하기 #2. SetWindowsHookEx() 소개

frontjang — Sat, 11 Feb 2012 13:10:59 +0900

이전글(P/Invoke로 다이얼로그 창 제어하기 #1. 현재 프로세스 제어)에 이어서 계속 진행됩니다.

이 기술의 핵심은 SetWindowsHookEx() WINAPI를 사용하는 것입니다. 이에 대한 설명은 MSDN 페이지(SetWindowsHookEx function)에 잘 나와있으며, 이를 번역, 요약하여 가져오자면 다음과 같습니다.

SetWindowsHookEx()는 훅 체인(hook chain)에 특정 어플리케이션을 위한 훅 프로시져를 추가합니다. 훅 프로시져를 설치함으로서 (특정 스레드에 한정되거나 혹은 전역적인)특정한 이벤트를 검출해낼 수 있습니다. 원형은 다음과 같습니다.

HHOOK WINAPI SetWindowsHookEx(int idHook, HOOKPROC lpfn, HINSTANCE hMod, DWORD dwThreadId);

idHook : 추가될 훅 프로시져의 종류이며, WH_CALLWNDPROC, WH_CBT 등의 값을 가집니다.
lpfn : 훅 프로시져의 포인터를 가리킵니다. 만약 dwThreadId가 0이거나, 현재 프로세스와는 다른 프로세스에서 만들어진 스레드의 식별자를 가리킨다면, lpfn은 DLL에 들어있는 훅 프로시져를 가리켜야 합니다. 혹은, lpfn은 현재 프로세스내에 위치한 훅 프로세스를 가리킬 수도 있습니다.
hMod : lpfn에서 가리켜진 훅 프로시저를 포함하는 DLL에 대한 핸들입니다. dwThreadId가 현재 프로세스에 의해 생성된 스레드를 가리키고, 훅 프로시저가 현재 프로세스내에 위치한경우, hMod는 NULL으로 설정되어야 합니다.
dwThreadId : 훅 프로시저가 연결될 스레드의 식별자입니다. 만약 이 값이 0으로 설정이 되어있다면, 훅 프로시져는 모든 스레드에 연결되게 됩니다(전역적)

* 참고사항
반환값으로 성공시 훅 프로시져에 대한 핸들을(lpfn), 실패시 NULL을 반환합니다. 프로세스와 DLL이 서로 다른 비트체계를 가질경우 동작하지 않으며, 32비트와 64비트 DLL은 서로 다른 이름을 가져야 합니다. 또한, hMod가 NULL이고 dwThreadId가 0 혹은 다른 프로세스에 의해 만들어진 스레드의 식별자를 갖는다면 오류가 발생할 것입니다.

훅 프로시저 뒤에 CallNextHookEx()를 실행하는것은 강제적이지는 않지만, 매우 권장하는 사항입니다. 이를 수행하지 않을 경우, 마찬가지로 훅을 추가한 다른 어플리케이션이 훅 이벤트를 받지 못할것이며 따라서 원하는 기능을 수행하지 못하기 떄문입니다. 다른 어플리케이션이 메시지를 받지 못하게 하려는 목적이 아닌이상 CallNextHookEx를 수행해야 합니다. 또한 종료전에 UnhookWindowsHookEx()를 실행함으로서 훅과 관련한 자원들을 해제시켜야 합니다.

=======================
너무 페이지를 잘게 쪼개 놓아도 불편하지만(많은 외국사이트가 이래놔서 귀찮음), 그래도 기술적인 소개를 할때 스크롤의 압박이 생긱면 괜시리 어려운 글인것처럼 느껴져서 읽기 싫어지는 경우가 있다. 딱 아래의 '요약글' 기능처럼 클릭하나로 다른 게시물의 내용을 보이고 감출 수 있으면 좋겠다. 비동기적으로 글내용만 추가하면 되니.. 한번 건의해볼만 한 기능인것 같다.

아무튼 SetWindowsHookEx()에서 인자값들이 중요하기에 정리해서 올려본다. 정리하자면, 만약 현재 프로세스에 한정해서 후킹을 하고 싶다.. 하면 lpfn은 함수포인터를 가리키고 nMode는 NULL, dwThreadId는 GetCurrentThreadId()으로 처리하면 된다는것이고(이전 게시물에서 적용되었던 내용), 그 이외는 DLL을 등록해서 사용해야 한다. 특히 .net에서는 전역후킹(global hook, dwThreadId=0 인경우)은 키보드와 마우스만으로 한정되기 때문에 이를 위해서 native DLL을 작성해야 한다.(다른 방법들도 있는것 같다)

원문보기

Installs an application-defined hook procedure into a hook chain. You would install a hook procedure to monitor the system for certain types of events. These events are associated either with a specific thread or with all threads in the same desktop as the calling thread.

The type of hook procedure to be installed. This parameter can be one of the following values.

A pointer to the hook procedure. If the dwThreadId parameter is zero or specifies the identifier of a thread created by a different process, the lpfn parameter must point to a hook procedure in a DLL. Otherwise, lpfn can point to a hook procedure in the code associated with the current process.

A handle to the DLL containing the hook procedure pointed to by the lpfn parameter. The hMod parameter must be set to NULL if the dwThreadId parameter specifies a thread created by the current process and if the hook procedure is within the code associated with the current process.

The identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.

If the function succeeds, the return value is the handle to the hook procedure.
If the function fails, the return value is NULL. To get extended error information, call GetLastError.

An error may occur if the hMod parameter is NULL and the dwThreadId parameter is zero or specifies the identifier of a thread created by another process.
Calling the CallNextHookEx function to chain to the next hook procedure is optional, but it is highly recommended; otherwise, other applications that have installed hooks will not receive hook notifications and may behave incorrectly as a result. You should call CallNextHookEx unless you absolutely need to prevent the notification from being seen by other applications.
Before terminating, an application must call the UnhookWindowsHookEx function to free system resources associated with the hook.

출처 : http://msdn.microsoft.com/en-us/library/windows/desktop/ms644990(v=vs.85).aspx

P/Invoke로 다이얼로그 창 제어하기 #1. 현재 프로세스 제어

frontjang — Fri, 10 Feb 2012 13:36:40 +0900

우선 이 게시물은 c#.net 으로 제작된 CodeProject의 Suppressing Hosted WebBrowser Control Dialogs 를 보완하는 내용임을 밝힙니다. 이 게시물은 내장된 WebBrowser의 다이얼로그 창 생성 이벤트 메시지를 검출해서, 다이얼로그 생성 이전에 다이얼로그를 처리함으로서 더욱 더 편한 사용자 환경을 제공하는데 목적이 있습니다. 여기에는 보안경고창(인증서 오류) 또는 ~으로 연결(사용자 이름과 암호가 필요한 창) 다이얼로그를 제거하는 역할을 하는데, 이를 응용한다면 javascript에서 발생하는 경고창 또한 제어할 수도 있습니다.

[그림 1] Spy++에서 확인한 alert(), prompt(), confirm()시 발생하는 자원.

위에 링크된 사이트에서 프로젝트파일을 다운로드 받은 후 핵심 부분인 WindowsInterop.cs를 열어봅니다. 후킹 프로시져는 WH_CALLWNDPROCRET_PROC으로서, 그 안에서 if (cwp.message == WM_INITDIALOG)이하, 즉 다이얼로그 생성시점을 체크하는 부분 아래부분을 확인합니다. 이곳에서는 GetWindowText()을 통해 얻어낸 윈도우 제목을 기준과 비교함으로서 원하는 창에 대해서 다시 검사하는 구조를 가집니다. if, else if로 두가지의 경우를 검출해 내지만 이 외에는 분기가 설정되어있지 않아 메시지가 다른곳으로 흘러가게 됩니다. 따라서, else if문을 추가하여 다른 경우를 설정해 주어야 합니다.

alert()의 경우는 [그림 1]에서 보시면 "웹 페이지의 메시지"라고 창제목이 설정된것을 확인할 수 있습니다. 따라서 else if (sb.ToString().Equals("웹 페이지의 메시지"))인 경우를 생각하면 되겠습니다. 단, 이경우 confirm()과 동일한 창 제목을 가지므로 내부에서 처리하는 로직이 또한 필요합니다. (아니면 무조건 확인으로..)

IntPtr pOkButtonHwnd = IntPtr.Zero;

foreach (IntPtr pChildOfDialog in WindowsInterop.listChildWindows(cwp.hwnd)){
// sbProbe에 현재 객체의 클래스명(Button, Static등)이 들어간다.
    StringBuilder sbProbe = new StringBuilder(255);
        if (GetClassName(pChildOfDialog, sbProbe, sbProbe.Capacity) != 0 &&
            !String.IsNullOrEmpty(sbProbe.ToString())){
// 만약 현재 객체의 클래스명이 Button이라면,
            if (StringConstants.WindowTypeButton.Equals(sbProbe.ToString(),
                StringComparison.InvariantCultureIgnoreCase)){
// 현재 버튼의 텍스트길이를 받아와서,
                iLength = GetWindowTextLength(pChildOfDialog);
                if (iLength > 0){
                    StringBuilder sbText = new StringBuilder(iLength + 1);
                    GetWindowText(pChildOfDialog, sbText, sbText.Capacity);
// 문자열의 길이가 0보다 큰경우 확인버튼인가 체크.
                if (StringConstants.ButtonTextOk.Equals(sbText.ToString(),
                        StringComparison.InvariantCultureIgnoreCase)){
// 현재 객체의 포인터를 저장한다
                        pOkButtonHwnd = pChildOfDialog;
                    }
                }
           }
        }
    }
    if (pOkButtonHwnd != IntPtr.Zero){
// 확인 버튼이 존재할 경우 그 버튼을 가지는 윈도우 핸들을 가져오고, 거기에 메시지를 보낸다
        Int32 ctrlId = GetDlgCtrlID(pOkButtonHwnd);
        SendMessage(cwp.hwnd, WM_COMMAND, new IntPtr(ctrlId), pOkButtonHwnd);
// 처리 후 다이얼로그 생성 메시지가 다른곳으로 흘러가지 않도록 끊어준다
    return 1;
}

단, 이 경우는 현재 프로세스에 내장된 WebBrowser에서의 메시지만을 담당하기 때문에 다른 창에서의 메시지를 확인할 수 없습니다. 따라서 Global Hooking등을 통하여 iexplorer들의 메시지를 확인하는 방법을 찾아야 하며, 이에 대해서는 다음 게시물에서 다룰 예정입니다.

솔라리스 콘쉘 프롬프트를 도스처럼 사용하기

frontjang — Thu, 09 Feb 2012 23:54:26 +0900

[그림 1, 2] ksh 프롬프트와 cmd 프롬프트

도스 프롬프트는 c:\Documents and Settings\na 처럼 현재 작업 디렉토리를 출력합니다. 하지만 솔라리스의 기본 프롬프트는 단순히 #(bash), >(tc) 아니면 $(ksh), 등으로만 나타나기 때문에 pwd를 쳐야하는 번거로움을 안겨줍니다. 하지만 이를 극복하기 위한 방법들이 있으며 그중 하나로 콘셸에서는 다음의 디폴트 변수를 사용할 수 있습니다

EDITOR : 셸을 위한 디폴트 에디터를 정의합니다
FCEDIT : fc명령을 위한 에디터를 정의합니다.(이전에 실행한 명령어를 다시 불러오는)
HOME : cd 명령을 인자없이 사용하였을 경우 갈 디렉토리를 지정합니다.
LOGNAME : 사용자의 로그인 이름을 정합니다.
PATH : 셸이 명령을 수행해야 할 때 실행파일을 찾을 디렉토리들을 콜론으로 구분지어 사용합니다.
PS1 : 프라이머리 콘셸 프롬프트를 지정합니다.(기본은 $)
PS2 : 세컨더리 콘셸 프롬프트를 지정합니다.(기본은 >)
SHELL : 셸의 이름을 지정합니다.

셸 프롬프트를 지정하는 변수로 PS1, PS2가 있으며. 여기서는 PS1를 변경하면 됩니다. 출력되는 프롬프트 부분은 echo "$PS1" 으로 표현할 수 있겠습니다. 만약 PS1=`pwd`라고 치게 된다면 어떻게 될까요, "pwd의 결과" 값이 PS1에 저장되게 됩니다. 이런 경우, cd로 디렉토리를 바꿔도 "pwd의 결과가 값으로 저장된 것"을 불러오기 때문에, 출력은 변하지 않게 됩니다. 또, PS1=$PWD라고 치게 되더라도 마찬가지 결과가 나오게 됩니다. 그럼 과연 어떻게 해야 할까요?

답은 ' '에 있습니다. PS1='$PWD'로 치면 '는 내부의 메타문자를 인식하지 않고 일반 문자로 저장하게 됩니다. 만약 메모리를 뜯어서 본다면, PS1은 $PWD 라는 문자를 저장하고 있을것입니다. 이제 프롬프트 부분을 봅시다. echo "$PWD"는 결국 pwd의 결과를 출력하고, cd를 바꾸면 그에 맞춰서 pwd의 결과를 출력 할 수 있을겁니다. dos와 똑같은 형태를 출력하기 위해 PS1='$PWD>' 로 지정해주면 [그림 2]와같이 출력이 됩니다.

여기에 추가로, 도스에는 유용하게 쓰이는 기능인, 화살표 위 아래키를 누르면 지난 명령의 목록이 뜨는 기능 또한 추가해 보겠습니다. 이것 역시 콘셸 기본 변수를 조작하면 비스무리 하게 할 수 있습니다. 화살표키를 사용할 수 없기 떄문입니다. 대신 vi에서 하던것처럼 j키와(아래로), k키(위로), l(오른쪽), h(왼쪽)를 누르시면 됩니다. 이것 역시 간단합니다. export EDITOR=/bin/vi를 입력하시거나. 혹은 export VISUAL=/bin/vi 또는 더 짧게, set -o vi 를 입력하시면 됩니다.

그리고 또하나, dos에서 쓰이던 dir이 그리우신 분들을 위해 alias가 존재합니다. 긴 명령이거나 외우기 어려운 명령, 그리고 옵션이 필요한 경우에 사용자가 원하는 명령어로 대치시켜주는 역할을 합니다 $ alias 하시면 grep, hlstory 등, 많은것들이 뜨게 될것입니다. 만약에 alias가 없었더라면 passwd 파일에서 루트유저의 정보를 보고싶을 때, cat /etc/passwd | /usr/bin/grep root 라고 쳐야 했을 것입니다.

도스에서 dir을 하면 아래 화면처럼 뜨게 됩니다. 솔라리스의 ls -l과 상당히 흡사하므로, ls -l을 dir라고 별명을 붙여줍시다(alias). 별명 붙이기도 쉽습니다. alias dir="ls -l"이라고 주시면 됩니다 앞으로 dir을 부르면 ls -l이 실행됩니다. 만약 이 설정을 취소하고자 한다면 unalias dir 하시면 바로 삭제됩니다.

[그림 3, 4] 각 운영체제에서의 dir 명령

=============
오늘도 새 글을 쓸 시간이 없어 글을 이동해왔다. 옛날 블로그 글들을 보면 뭐 이런 잡스러운걸 적어놨나.. 해서 은근 가져오기가 까다롭다, 물론 그때에 비해서 지식의 깊이나 폭이 넓어져서 그렇겠지만, 기존 게시물을 내가 현재 아는것과 함께 보완해서 적으려고 하면, 이걸 어느정도 깊이로 써야 할까 하는것도 고민하게 된다. 아직 고수로의 길은 멀기에, 만족하는 깊이만큼 쓰려면 그만큼 더욱 공부해야 하는데 그러기도 여의치 않기 때문이다. 그렇다고 막 쓰자니 글을 쓰는 의미가 없고. (그래서 오늘글은 의미없는 글?)

DELIUS: Piano Concerto / RAVEL: Jeux d'eau (Moiseiwitsch, Vol. 6)

frontjang — Wed, 08 Feb 2012 23:36:54 +0900

DEBUSSY, CLAUDE

01. Estampes: Jardins sous la pluie 3:00

02. Suite bergamasque: Clair de lune 4:19

03. Pour le piano: Toccata 3:34

RAVEL, MAURICE

04. Jeux d'eau 4:39

05. Le Tombeau de Couperin: Toccata 3:44

GRANADOS, ENRIQUE

06. Danza espanola in E minor, Op. 37, No. 5, 'Playera' 3:06

07. Danza espanola in D major, Op. 37, No. 6, 'Jota' 3:03

IBERT, JACQUES

08. Histoires: Le petit âne blanc 1:56

POULENC, FRANCIS

09. Mouvement perpetuel No. 1 in C major 1:34

STRAWINSKY, IGOR

10. Etude in F sharp major, Op. 7, No. 4 1:40

PROKOFIEFF, SERGE

11. Suggestion diabolique, Op. 4, No. 4 2:45

VALLIER, JOHN

12. Toccata 1:22

GODOWSKY, LEOPOLD

13. Concert Paraphrase on 'Die Fledermaus' 8:16

CHASINS, ABRAM

14. Flirtation in a Chinese Garden, Op. 5 2:09

15. Rush Hour in Hong Kong, Op. 6 1:20

PALMGREN, SELIM

16. Rococo, Op. 47, No. 5 2:53

17. Refrain de berceau 2:59

18. West Finnish Dance 1:33

DELIUS, FREDERICK

Concerto for Piano and Orchestra

19. I. Allegro non troppo 9:21

20. II. Largo 6:19

21. III. Tempo primo 5:24

====================
예전에 드뷔시와 라벨에 대해 관심이 많았을때 이 음반을 봤었다. 비록 1940년대에 녹음되어 음질이 좋지 않았지만, 연주가 살아있었고, 오래된 음반 특유의 텁텁한 음색(?)도 좋아하기 떄문에 이 음반을 기억해 두려 했었다. 또한 많은 새로운 곡들이 있어서.ㅡ하지만 잊고 있었다.

그러다가 우연찮게 다시 발견한 앨범. 반가운 마음에, 처음들은 곡중에서 가장 맘에 들었던 15번 트랙, CHASINS, ABRAM의 Rush Hour in Hong Kong을 틀게 되었다. 구수한 음색과 빠르지만 혼란스럽지 않은 부드러움? 거기에 중국의 이미지가 묻어나는 곡 특유의 색깔까지. 또한 드뷔시의 곡들은 적당히 빠른데다가 음색이 텁텁(뭔가 좋은 표현이 있을텐데.)해 져서 몽환적인 분위기 마저 나타낸다.

Pour le piano: Toccata도 마찬가지다. 평소에 이곡을 치면 약간 날카로운 느낌이 없잖아 있는데(뭐 기교상의 문제겠지만.) 이 음반은 높은톤을 뭉개줘서 훨신 포근하다. 곡선정도 정말 잘한것 같다. Jeux d'eau처럼 분주하면서도 단순한 형태의 곡들이 많다. (그걸 자극적이지 않게, 빠르지만 부드럽게 치는것.) 욕조에 물받아놓고 그옆에 스피커로 이 앨범을 틀면 정말 환상적일거 같다? 정말 '물의 유희'겠군. 이제 이 페이지에 기록을 해놓았으니 잊을 일은 없겠다.

이상 블로그 스팟에 있던글을 잘라내기->붙여넣기 하였다. '2월중 매일 블로그에 글쓰기'를 목표로 하고 있는데(소재는 충분하다) 가끔 바쁜날이 닥쳐서 새로운 글을 쓰기 부담스러울 때엔 이렇게 예전 블로그들에서 글을 옮겨와야겠다. 옮겨오면서 쓸데없는 이모티콘등을 제거하였다. 티스토리로 옮겨오면서 본문에 왠만하면 이모티콘을 사용하지 않기로 마음먹었는데 참 잘한 결정인것 같다.

관련포스트 : The Romantic Piano Concerto, Vol. 39 – Delius & Ireland

Chasins Rush hour in Hong Kong moiseiwitsch

WebBrowser Control 사용시. 페이지로딩이 완료되었는지 확인하기

frontjang — Tue, 07 Feb 2012 11:57:55 +0900

WebBrowser 컨트롤은 웹페이지 로드가 완료되는 시점에서 DocumentComplete이벤트를 생성하며, 이를 위해 이벤트 핸들러를 만들어 처리할 수 있습니다. 이 게시물은 WebBrowser 컨트롤 사용시 페이지 로딩의 완료여부를 판별할 수 있는 방법들에 대해 소개합니다.

WebBrowser 컨트롤은 ReadyState 속성이 READYSTATE_COMPLETE로 변했을때 DocumentComplete 이벤트를 생성합니다. 이 이벤트는 WebBrowser 컨트롤이 웹페이지 다운로드를 완료했다는것을 의미합니다. 해당 이벤트에 대해 알아두어야 할 사항은 다음과 같습니다.

페이지에 프레임이 없는 경우(단일페이지), DocumentComplete는 페이지 로드 완료시 한번만 발생된다.
여러 프레임이 존재하는 경우 DocumentComplete도 마찬가지로 여러번 발생된다. 모든 프레임이 이 이벤트를 발생시키는건 아니지만, DowonloadBegin 이벤트를 발생시키는 모든 프레임은 이에 상응하는 DocumnetComplete를 발생시킨다.
DocumentComplete 이벤트 발생시, 인자값으로 해당 프레임의 IDispatch를 가리키는 IDispatch* 를 갖는다.
최상위(DOM) 프레임은 가장 나중에 DocumentComplete를 발생한다. 그러므로 페이지 로드 완료를 확인하기 위해서, IDispatch* 인자값이 WebBrowser 컨트롤의 IDispatch와 동일한 항목을 가리키는지 확인하면 된다.

비주얼 베이직으로 페이지가 모두 로드되었는지 확인하는 방법은 다음과 같습니다

Private Sub WebBrowser1_DocumentComplete(ByVal pDisp As Object, URL As Variant)
    If (pDisp Is WebBrowser1.Object) Then
        Debug.Print "Web document is finished downloading"
    End If
End Sub

만약 최상위 프레임이 변하는것이 아니라, 프레임 독자적으로 페이지가 변하는 경우, DocumentComplete는 최상위 프레임이 아닌, 해당 프레임의 로드가 완료되는 시점에서 호출이 됩니다. 다음와 같은 경우를 생각해보세요

WebBrowser 컨트롤이 frameset을 포함합니다. frameset에 속하는 어떤 프레임상에서 유저가 한 링크를 클릭하여 그 프레임 상에서 새로운 페이지를 불러옵니다 (단, 다른 프레임들의 변화는 없습니다) 새로운 페이지 내에는 또다른 여러개의 프레임이 존재할 수 있습니다. 따라서 각각의 하위 프레임마다 DocumentComplete 이벤트가 발생하게 됩니다. 하지만 최상위 프레임이 변하지 않았기 때문에, DocumentComplete가 가장 마지막으로 호출 될때의 IDispatch는 새로운 페이지를 포함하는 프레임을 가리키게 될 것입니다.

이러한 경우에서, 가장 마지막으로 발생하는 프레임을 찾는데에 관심이 있다면, DocumentComplete에서의 IDispatch가 가장 먼저 호출되는 NavigateCompete2 이벤트에서의 IDispatch와 동일한 값을 갖는지 확인하는 방법을 사용하실 수있습니다. 최상위 프레임을 로드할때에 가장 먼저 NavigateComplete2가 발생하고, 마찬가지로 최상위 프레임이 최종적으로 로드된 시점이 바로 마지막 DocumentComplete가 호출되는 시점이기 때문입니다. 아래 C++ 코드를 참고하세요

LPDISPATCH glpDisp = NULL; //전역 LPDISPATCH

void CWebbrDlg::OnNavigateComplete2Explorer1(LPDISPATCH pDisp, VARIANT FAR* URL) {
// glpDisp가 NULL인지 확인한다. NULL일 경우 현재 최상위 프레임을 다루고 있다는것을 의미하므로 LPDISPATCH를 저장한다
    if (!glpDisp) glpDisp = pDisp;
}

void CWebbrDlg::OnDocumentCompleteExplorer1(LPDISPATCH pDisp, VARIANT FAR* URL) {
    if (glpDisp && glpDisp == pDisp) {
    // 만약 DocumentComplete에서의 LPDISPATCH와 기존 전역변수에 저장한 값이 동일한값을 가질경우 이는 최종적으로 페이지가 로드되었다는것을 의미한다. 다음 사용을 위하여 glpDisp를 초기화한다.
       TRACE("Document is done downloading");
        glpDisp = NULL;
    }
}

원문보기

The Internet Explorer WebBrowser control fires the DocumentComplete event when it is finished downloading a Web page. You can create a event handler function in your application for this event. This article describes the steps to take in determining if a the WebBrowser control is finished downloading a Web page.

The WebBrowser control fires the DocumentComplete event when its ReadyState property is changed to READYSTATE_COMPLETE. This indicates that the WebBrowser control has completed downloading the Web page. Here are some important points regarding this event:

In the case of a page with no frames, DocumentComplete is fired once after everything is done.

In case of multiple frames, DocumentComplete gets fired multiple times. Not every frame fires this event, but each frame that fires a DownloadBegin event fires a corresponding DocumentComplete event.

The DocumentComplete event has a IDispatch* parameter, which is the IDispatch of the frame (shdocvw) for which DocumentComplete is fired.

The top-level frame fires the DocumentComplete in the end. So, to check if a page is done downloading, you need to check if the IDispatch* parameter is same as the IDispatch of the WebBrowser control.

This approach works when the WebBrowser control navigates to a page that changes the top-level frame. Say if the navigation occurs within a frame itself, then the final DocumentComplete that is fired is that of the frame and not the top-level frame. For example, consider the following scenario.

The WebBrowser control is hosting a frameset. Within one frame of the frameset, the user clicks on a link that opens a new page in the frame itself and keeps the rest of the frameset intact. The new page could contain multiple frames again. So, there will be multiple DocumentComplete notifications (one for each new frame). But, since the top-level frame has not changed, the final DocumentComplete would be that of the frame that has changed.

If you are interested in checking for the final document complete in this scenario, you could do the following:

Check if the IDispatch parameter of the DocumentComplete is the same as the IDispatch parameter of first NavigateComplete2 event. Since the first NavigateComplete2 is of the top-level frame and the last DocumentComplete is also of the top-level frame, doing a comparison in such a fashion will tell whether the page is done downloading.

출처 : http://support.microsoft.com/kb/180366/en-us

JFace MenuManager 사용하기 #1. 프로그램 상단메뉴 추가

frontjang — Mon, 06 Feb 2012 21:26:49 +0900

JFace MenuManager는 SWT 메뉴의 생성과 업데이트를 쉽게 할 수 있도록 도와줍니다. MenuManager는 아이템, 또다른 MenuManager(하위메뉴를 위해), 그리고 분리자를 포함할 수 있습니다. MenuManager는 바메뉴, 팝업메뉴, 드랍다운 메뉴등으로 표현될 수 있습니다. 뷰어(viewer)에서와 마찬가지로, MenuManager는 SWT 메뉴 자체에 대해 직접적인 접근을 요하지 않는, '헬퍼객체'라 할 수 있겠습니다. MenuManager뿐만 아니라 버튼, 툴바객체에도 액션(Action)을 추가할 수 있으며, 이는 ① Action을 상속받는 서브클래스를 만들고, ② 메뉴/툴바/버튼에 나타나고자 하는 텍스트를 설정하고, ③ run() 메소드를 구현함으로서 원하는 작업을 할 수 있습니다.

아래의 코드를 확인해보세요. Exit에서 x앞에있는 &문자는 x가 해당 메뉴 아이템의 바로가기 키(포커스를 옮겨주는 역할)라는 것을 나타내줍니다. 이는 단축키와는 다른 개념이며 단축키는 @뒤에 조합을 위치함으로서 설정이 가능합니다(Ctrl+W). 물론 단축키를 직접 설정하는 메소드도 존재합니다. setToolTipText()로 툴팁(마우스를 올려놓았을때 나오는 노란색 설명)을 설정할 수 도 있으며 메뉴 좌측에 위치하는 메뉴 설명 그림 또한 setImageDescriptor()으로 추가할 수 있습니다. 단 메뉴 설명 그림이 추가된 경우 메뉴 아이템에 툴팁이 보이지 않겠지만, 이는 ToolbarItems를 통해서 사용 가능합니다

단, 자세히 보신분은 눈치채셨겠지만 이 구현에서는 Action상에서 이미지 descriptor를 직접적으로 사용합니다. 실제로는 이미지 레지스트리에서 이미지 descriptor를 가져오는것이 좋겠지만, 문제는 이미지 레지스트리는 단지 이미지만을 반환하며 ImageDescriptor를 받을 수 없다는 것입니다. 이 버그는 이클립스 버그 데이터베이스 23555 에 기록되어있습니다.

import org.eclipse.jface.action.*;
import org.eclipse.jface.window.*;
import org.eclipse.jface.resource.*;
import org.eclipse.swt.*;

public class ExitAction extends Action {
    ApplicationWindow window;

    public ExitAction(ApplicationWindow w) {
        window = w;
        setText("E&xit@Ctrl+W");
        setToolTipText("Exit the application");
        setImageDescriptor(ImageDescriptor.createFromURL(Util.newURL("file:icons/close.gif")));
    }

    public void run() {
        window.close();
    }
}

Action을 상속받는 클래스 만들기
Action에 getText()가 정의되어있다는 사실때문에 혼동될 수 있지만, 이것을 오버라이드하려는 것이 아닙니다. 대신, Action은 setText(String)을 통해서 text값을 받아와 저장하며, Action을 사용하는 모든 SWT 컨트롤에 대해서 주어진 새로운 텍스트값을 갖도록 한다는것을 알아야 합니다. 이 사항은 툴팁 텍스트, 활성화 상태등과같은 모든 Action 속성에 적용되는 사항이며, 이에 대해서는 다음에 살펴보겠습니다.

어플리케이션 윈도우에 메뉴바 추가하기
이제 어플리케이션 윈도우(ApplicationWindow)에 addMenuBar()를 통하여 메뉴바를 추가하는 작업을 해보겠습니다. 기억해야 할 사항은, 이 작업은 SWT shell이 만들어지기 이전에 실행되어야 한다는 것입니다. 또한 이는 어플리케이션 윈도우에 들어있는 메소드인, createMenuManager()를 통해 작업이 이루어지며, 이 메소드의 리턴값으로 MenuManager가 반환됨으로서 SWT 메뉴바를 만드는데 사용되게 될것입니다. 아래 코드에서, 하위 MenuManager가 add()되지 않은 메뉴는 자동으로 비활성화 상태로 변하며, 또한 Alt+F, x를 누름으로서 어플리케이션을 닫으실 수 있습니다.

protected MenuManager createMenuManager(){
    MenuManager bar_menu = new MenuManager("");
    MenuManager file_menu = new MenuManager("&File");
    MenuManager edit_menu = new MenuManager("&Edit");
    MenuManager view_menu = new MenuManager("&View");

    bar_menu.add(file_menu);
    bar_menu.add(edit_menu);
    bar_menu.add(view_menu);

    file_menu.add(new ExitAction(this));
    return bar_menu;
}

Menus
The JFace MenuManager simplifies the creation and updating of SWT menus. A menu manager can contain items, other menu managers (for submenus), and separators. Once you have created a menu manager, it can be represented by either a bar menu, a context menu (in other words, a pop-up menu), or a toolbar drop-down menu.
Just as with viewers, a menu manager is a helper object rather than a wrapper object, although you will generally not need to access the SWT menu itself. Before we discuss menus, let's see what can go into a menu manager.
Actions
You add actions to menu managers. Actually, you can add actions to buttons and toolbars, too. The idea is that you subclass Action, set the text that you want to appear in the menu/toolbar/button, and implement the run() method to make it do what you want.
Let's dive straight into an example: ExitAction, shown in Listing1.

All fairly simple. The & character before the x in Exit indicates that x is to be the keyboard navigation key (mnemonic) for this menu item. Note that this is different from a key accelerator (hotkey). We'll see these soon.

We've added an accelerator key (hotkey), a tool tip, and an image (the tool tip won't show up on menu items, but it will on toolbar items, which we'll see later). There is a method to set the accelerator key directly, but it's easier to specify it in the text after the @ character, since it gets added into the text of the menu item, as shown in Figure 3.

The eagle-eyed reader may have spotted that we supplied an image descriptor directly to the action. What we would really like to do is get the image descriptor from the image registry. The problem is that the image registry only gives out Images. You can't ask it for an ImageDescriptor. This is bug 23555 in the Eclipse bug database.

Subclassing actions
Don't be misled by the fact that Action defines the method getText(). You are not intended to override it. Instead, you are meant to use setText(String), and Action will store it and ensure that all the SWT controls that are currently using this action are updated with the new text.
This applies to all the other Action properties like the tool tip text, its enabled state, etc. We'll see these later.
Adding a bar menu to an application window
We need to configure the application window to have a bar menu using this method in ApplicationWindow: protected void addMenuBar().
Remember that we must do this before the SWT shell is created. And this will call the application window method createMenuManager(), which returns the menu manager that it will use later to create the SWT Bar Menu. Here is our implementation.
Note that the menus that are empty are disabled. Try closing the explorer application using the navigation keys Alt+Fx.

출처 : http://www.ibm.com/developerworks/opensource/library/os-ecgui3/#resources

슈어 헤드폰을 위한 (저렴한)교체형 선 사용기

frontjang — Sun, 05 Feb 2012 13:55:25 +0900

오래전부터 알려져 왔던 방법이긴 한데 인터넷에 관련글을 찾아보기 힘들어 적어본다. 요는 슈어 헤드폰(SRH, 확인된 모델로 SRH440, SRH840)시리즈중 케이블 탈착이 되는 제품은 양단이 2.5-3.5 파이인 표준 스테레오 단자를 사용한다는것이다. 단, 헤드폰과의 선의 연결에 있어 분리를 어렵게 하기 위하여 헤드폰쪽에는 특이한 모양의 홈이 있어서(사진 참고), 자작 케이블을 만드는 분들은 이를 따라하기 위해 선을 깎으시던데, 굳이 이렇게 할 필요는 없는것 같다.

그럼 왜 굳이 케이블을 새로 장만해야 하는가? 한다면, 위 사진을 보면 바로 이해가 될 것이다. 무려 3미터의 두꺼운 돼지꼬리 케이블이 헤드폰과 연결되어 있어 헤드폰의 체감 무게를 증가시킬 뿐 아니라 아웃도어 용으로 사용하기에 부담스러운 미관을 보여준다. 물론 플랫한 케이블을 정식으로 판매한다고도 하나 그것 역시 길고 두꺼우며, 가격적으로 문제가 될 수 있다. 약간의 음질의 손실(아래 계속)이 있더라도 매우 저렴한 케이블을 사는것이 정신적으로 좋다.

그럼 그 케이블은 어디에서 살 수 있는가? 물론 어디에서건 양단이 수(male)인 2.5-3.5 스테레오 케이블을 구매하면 된다. 하지만 인터넷에서 확인을 하지 않고 사다보면 간혹 말단부(헤드폰에 끼워지는 2.5파이 단자를 감싸는 부분)가 너무 두꺼워 깎아야 하는 문제가 발생할 수 있는데, 우편으로 무료로 배송해주는 해당 옥션 페이지에서 구매하여 만족스러운 물건을 받을 수 있었다. 가격도 무려 2000원. 케이블이 단선된다? 새로 사면 된다!

처음 사고 나서 헤드폰에 선을 꽂으면 잘 안들릴 수 있다. 헤드폰 내부의 홈에 걸리기 떄문이다. 이때 약간 무리하는 느낌으로 세게 한번 눌러주면(강도 조심!) 위와같이 미세한 홈이 생긴다. 이 홈이 생긴 후 마치 나사돌리듯이 돌리면서 헤드폰과 선을 연결해주면 내부의 홈과 위의 부분이 잘 결합이 되며, 힘주어 당기지 않는 한 잘 떨어지지 않는 상태가 된다. 그리도 선을 분리할 경우에도 반대방향으로 돌리면서 선을 뽑으면 이 역시 잘 뽑아진다. 단, 인위적으로 홈을 만든 후 선을 꽂으려 하면 내부의 홈과 접하지 않고 헛돌게되는 경우도 있으므로 헤드폰의 내부구조를 사용하여 홈을 만드는것이 좋을 것 같다.

이 케이블을 사용하면 가장 먼저 느끼게 되는것이 헤드폰 무게의 감소이다. 헤드폰 선을 매달아놓고 사용하지 않는 한, 중력에 의해 헤드폰 선의 무게도 헤드폰의 무게로 포함되어 장시간 감상시 목이 아파오는 현상이 발생하는데 이 케이블을 사용하면 현저히 무게가 감소된것이 느껴지며 더 오랜 시간 감상이 가능하다. 그리고 무엇보다도 아웃도어에서 사용하는데 부담이 적어진다(그 긴 케이블을 주머니 속에 쑤셔넣느라 주머니에 넣을 수 있는것이 없었다, 물론 요다현상때문에 아웃도어에는 일정수준 이상의 용기가 필요해 보이지만 나는 용자니까!)

하지만 음질에 있어서 기본 제공되는 OFC(무산소동선) 케이블과 비교해보면 차이가 나게된다. 특히 전체적으로 해상도가 약간 떨어지는 대신 저음부가 미세하게 강화되는 느낌을 받았다. 앨범의 경우를 들자면 아래와 같다. Jacqueline Du Pre, Janet Baker - Elgar: Cello Concerto / Sea Pictures 앨범에서의 Sea Pictures에서는 Janet Baker여사의 맑고 힘찬, 그리고 부드러우면서도 음을 찌르는듯한 목소리가 인상깊은데, 이 케이블을 사용하면 그 목소리가 매우 얇은 '막'으로 가려져서 명료함이 줄어드는 느낌을 받는다. 또한 Mondo Grosso - MG4 에서의, Star Suite II: Fading Star 에서 D->G 코드로 진행하는 부분 이후, 그동안 인지하지 못했던 2초정도 지속되는 저음의 미세한 떨림이 느껴지기도 하였다. 또한 전체적인 드럼파트(특히 킥드럼)이 강조된것을 느낄 수 있었다.

저음이 부족하다 여겨지는 SRH440을 사용하고 있는데 오히려 저음이 강화되는 부분이 보완점으로도 작용할 수 있다고 생각한다, 헤드폰 튜닝시에도 저음을 강화시키기 위해 음질을 약간 감소시키는 방법을 사용하기도 하는데(덧대기 등) 이렇게 선재를 바꾸는것으로 편의성을 증가시킬 뿐 아니라 음의 변화를 꾀할 수 있다면 시도해도 나쁘지 않는 방법이라 생각한다.